scope of malloc

[Richard A. O'Keefe]

In article <11631 at alice.att.com>, ark at alice.att.com (Andrew Koenig) writes:
: Seriously, though, if one decides to make it impossible to support
: alloca(), as the definition of ANSI C allows, it is sometimes possible
: to produce significantly faster object code as a result.

We are still waiting to be told about any machine on which this is true.

: For example, barring alloca() means that the compiler can always know
: the size of the stack frame.  That, in turn, means that it is possible
: to maintain the stack using only a single pointer.  That implies that
: a function call need update only one stack register and not two.

This is just sloppy thinking.  It has been pointed out several times
that the compiler can always know the size of the stack frame for any
function in which alloca() does not actually occur.  Indeed, whoever
said alloca() had to allocate memory from the current stack frame?
The argument "alloca() means you have to use more than one stack register"
is completely false.  The significant point about alloca() is that the
space goes away when you exit the function, whether by normal return or
by longjmp().  There is no promise, for example, that memory allocated by
two successive calls to alloca() is contiguous.  (The natural implementation
of alloca() on a Prime 400, for example, using the P400's stack extension
instruction, would yield no such guaranteee.)  I sketched an implementation
of alloca(), based on traditional Algol techniques, in which *every* function
could use the one-register frame-size-always-known protocol whether alloca()
was used or not.

The following statement appears to be true:
    with a small amount of compiler support,
    and a small overhead in longjmp(),
    alloca() can be implemented as efficiently as malloc() or better
    on any machine that can support C
I outlined the method in an earlier posting.

Whether alloca() is _worth_ implementing is another question.
-- 
I am not now and never have been a member of Mensa.		-- Ariadne.