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

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Wed Apr 23 16:25:01 PDT 2008


Let me summarize...
(patches)
Ok, that makes sense to have the patches applied by someone else,
however, my patches will surely break other peoples work. I'm just
curious, how are you going to merge them? Conditional compiling?
Commandline flags? 

(Enforcing no recursion)
We are also implementing our own linker. In fact not only the recursion
thing, but also many other features can't work without a custom linker;
I can go over some details separately if you are interested.
 
(llvm backend)
We have the code generation in llvm, although it is not complete, it is
just enough to prove the concept. The register spilling and other stack
dependent things will be handled in an unconventional way on the
function frame (the memory locations will be reserved at link time). The
linker can even decide if it can reuse (overlay) some of these frames
depending on how call graph looks like.

(alloca)
We tried code generation in llvm by replacing alloca with global
addresses however, (1) the name of local variable is not as easily
available, (2)I don't feel quite comfortable with having the storage
class of variable change at the last phase of translation. It sounds
more reasonable to get it right in the front-end to begin with.

Regards,
Ali

-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Wednesday, April 23, 2008 3:33 PM
To: Alireza Moshtaghi - C13012
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] stack-less model on small devices

(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




More information about the cfe-dev mailing list