[cfe-dev] stack-less model on small devices

[Eli Friedman]

(Resend, this time with the the list on the CC list.)

On Wed, Apr 23, 2008 at 12:21 PM,  <Alireza.Moshtaghi at microchip.com> wrote:
>
> Hi
>
> I am using clang/llvm to implement a c compiler for an 8-bit microprocessor.
> I apologize for the lengthy email, but I think it is necessary to give a
> background of what I'm doing and then ask my questions.
>
> Stack operations are not practical on this device because the memory is
> composed of small pieces that are not contiguous in address space. So we
> have to sacrifice recursion and play some tricks in llvm to implement things
> like reentrancy, function pointers, varargs, etc.

Hmm, so you're statically allocating everything everything, at the
expense of not being able to support recursion?  Interesting.  I don't
think there are any existing LLVM ports to an architecture that don't
have a stack.

I don't think it's possible to enforce a "no recursion" rule using a
conventional C linker, so I guess you'd have to be careful when
writing code for an architecture like this.  (I guess you could use a
runtime check so the program doesn't silently fail.)

> At a high level:
>
> 1) Function frames are statically allocated at link time and they contain
> the local variables, input arguments, return address, etc.
>
> 2) Auto variables behave like static local variables except for
> initialization (which must take place in the function preamble)
>
> 3) Parameters behave like local variables except for initialization (which
> must take place in the caller)
>
> 4) Global and Static local variables behave no different than standard c

Right... makes sense.

> Accordingly, I need to modify the front-end to generate the llvm-bitcode
> such that correct storage class/name-mangles are selected for variables.
>
>
>
> I modified CGDecl.cpp in the two functions below and so far everything works
> fine:
>
> CodeGenFunction::EmitParmDecl() {same as in EmitStaticBlockVarDecl(); except
> for initialization; also mangle the name differently}
>
> CodeGenFunction::EmitLocalBlockVarDecl() {same as EmitStaticBlockVarDecl();
> except generate the initialization code; also mangle the name differently}

I doubt this is really the best approach for doing this because of the
way LLVM works... the optimizers are much more effective when local
variables are allocas.   Also, this doesn't get rid of all the stuff
that would normally be allocated on the stack: sometimes, registers
have to be spilled onto the stack.

Have you actually tried writing an LLVM backend for your processor
yet?  It should be straightforward to add alloca support once you have
everything else working.

> 2) These modifications are in contrast with most microprocessors but are
> useful for many small devices (including the one I am working on), how
> should I go about incorporating these changes in the clang code base?

If you have patches, just send them to this list (just use "svn diff").

> 3) How can I acquire access privilege to be able to checkin to the clang
> code base?

Don't worry about it; someone else can commit your patches for you.

-Eli