Re: What's wrong with alloca() ?

Some time ago, I implemented alloca() for the Pr1me '50 series. This has
been used in a variety of applications without any problems being found.


In operation, it is called as a normal function (PCL instruction). It
first of all dismantles it's stack frame, and resets the top-of-stack
address held at the base of the stack. The link-base and stack-base
registers are also reset to the caller's values. The current stack frame
(which is now the caller's) is extended by the use of the stack-extend
(STEX) instruction, which can extend the stack by up to (nearly) a segment
(128Kb) each time. STEX leaves a pointer in a register, which is returned
to the caller, when a jump to the return address is made.


Once memory has been allocated in this way, there are no restrictions as
to its use; and there are no restrictions on the calling of other
functions. Many calls to alloca() may be made, as and when memory is
required. When the calling function itself returns, the extra stack space
allocated is retrieved. No compiler support is required; and nested
function calls pose no problem.


Those of you familiar with Pr1me may be asking, "why not shortcall
alloca()?". I chose to make it a standard function primarly to facilitate
its use by those unfamiliar with shortcall. (Shortcall is a fast function
call, where the called function shares the caller's stack frame; and
cannot be nested)


As a side-effect of this, if alloca() is called by a function which is
itself shortcalled, the space remains allocated until the caller's caller
returns. This allows a longer "lifetime" for the allocated space than is
usual. There would be no problem in implementing an inverse function to
free the space allocated by alloca(); but it would have to be used with
care!
--

Return to the comp.compilers page.
Search the comp.compilers archives again.