alloca

[Karl Heuer]

In <19895 at cornell.UUCP> aitken at svax.cs.cornell.edu (William Aitken) writes:
>In <8293 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>The C vendors aren't evil (?) either; requiring support for alloca()
>>does impose an undue burden on implementations on some architectures.
>>
>Could someone give a concrete example of an architecture on which alloca is
>difficult to implement, and explain what it is that makes automatic
>arrays possible, but alloca difficult?

The AIX compiler on the IBM RT/PC.  A single register is used for the stack
pointer, frame pointer, and arg pointer; the compiler generates appropriate
offsets based on its knowledge of the frame size%.  If (as in the usual
implementation of alloca) you tried to change the frame pointer on the fly,
all hell would break lose.

My conclusion (I analyzed this problem when porting GNU Emacs&, which makes
heavy use of alloca) was that a proper alloca would have to be written as a
compiler builtin$.  In this case the cost would be one extra register, in only
those functions that happen to use alloca.  This doesn't seem like an undue
burden.  I agree with the FSF on this one.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
________
% The frame size depends on the number of registers used by the current
  routine, the number of automatic variables, and the number of arguments
  passed to subroutines, but is independent of the number of arguments passed
  to the routine itself.  Thus variadic functions work too.
& Sorry, I'm no longer providing the Emacs diffs.  They're outdated.
$ I could almost have done it by postprocessing the .s file, but I couldn't
  find a way to get the compiler to not use all the registers.