> On Tue, Mar 12, 2002 at 11:54:16AM +0100, Jaromir Dolecek wrote:
> > David Laight wrote:
> > > Given that alloca() is an architectural nightmare, maybe you should
> > > abolish it completely and fix code not to assume it is present at all.
> > > 
> > > Get rid of setjmp/longjmp at the same time :-)
> > 
> > Dream on :)
> 
> On an embedded system I think someone was trying to longjmp
> out of an interrupt handler!
> 
> Thinking about it, you cannot write alloca without knowing
> how the compiler has compiled the rest of the routine.
> Indeed in some cases it cannot be written at all.
> 
> For instance, take a normal stack frame with frame ptr
> pointing somewhere near the stacked return address.
> Now instead of using 'push' for arguments, leave enough
> space when the stack ptr is decremented (on entry) for
> the arguments for the routine with most arguments and
> move the arguments to the stack with fp relative
> addressing.
> 
> It is then impossible to write alloca.
> The above scheme isn't stupid!  I think it is a performance
> gain on Pentium Pro (often sp relative addressing gets used,
> but I suspect that bloats the code size so much that it
> displaces other code from the cache and slows things down!)

Impossible is probably an overstatement.  Difficult, and inefficient, 
maybe.

As long as you have a concept of stack depth then it is possible to write 
an alloca.  You can even write it in C.

Things get trickier when your stack is fragmented, as can happen on non-vm 
systems; and even more tricky if you want threads, since then you have to 
track more than one alloca chain, but it's still possible.

Having said that, I really dislike alloca ;-)

R.