🚀 go-pugleaf

I've got what may be some naive questions here about alloca().

The gist of the discussion a week or two ago about alloca was that there
are some portability problems but it can improve efficiency relative to
using malloc.  No argument from me there, but...I'm currently dealing with
a compiler for the 386 which (with the optimizer on) doesn't set up %ebp
on entry to a procedure.  Instead, it references all parameters and locals
off %esp.

The way I know of to implement alloca() is as a function that fiddles the
saved stack pointer of the procedure calling it, creating a hole in the
stack for the locally-allocated storage.  Obviously this doesn't work if
the calling routine has compiled-in offsets from %esp to get to the first-
order ws in its frame.  Is there some alternative "good trick" for alloca()
that works if you don't have a separate frame pointer?  (Obviously I'm
looking for something more efficient than finding a way to map it to
malloc/free.  I can envision having a separate stacklike area for
allocation, but then deallocation is a problem if you don't fiddle the
compiler.)

About efficiency:  There is a substantial gain in programs which have
frequently-called small procedures, from not setting up %ebp.  I've
seen performance improvements of 20% on real programs.  The reason is that
you get rid of	pushl	%ebp
		movl	%esp,%ebp
		...
		leave
which is effectively two memory-referencing instructions and two reg-reg
ops per routine.  Isn't this a more significant efficiency gain, of more
general utility, than alloca?

...but as I said, I'm asking naive questions.  What am I missing?
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Simpler is better.