Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!gatech!udel!princeton!phoenix!haahr
From: haahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr)
Newsgroups: comp.lang.c
Subject: Re: alloca
Summary: why it is difficult or impossible
Message-ID: <3379@phoenix.Princeton.EDU>
Date: 2 Aug 88 17:33:06 GMT
References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp> <8293@smoke.ARPA> <19895@cornell.UUCP>
Reply-To: haahr@princeton.edu (Paul Gluckauf Haahr)
Organization: Princeton University, Princeton NJ
Lines: 41

in article <19895@cornell.UUCP>,
	aitken@svax.cs.cornell.edu (William Aitken) writes:
> 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?

in general, a compiler (rather, a run-time calling convention) that
does not use a register for the frame pointer (as opposed to a virtual
frame pointer) makes alloca() next to impossible.

alloca() counts on being able to munge the stack frame (by adding space
to it) without confusing the calling function.  functions
index off their frame pointers to refer to local variables, parameters,
and the function return address.  if the frame pointer is a real
register, there is no problem:  alloca() can decrement (or, rarely,
increment) the stack pointer appropriately and the calling function
probably won't notice.  but, as is more common with newer (RISC
influenced) compilers, the frame pointer is a virtual entity, really
just the stack pointer plus some offset:  munging the stack pointer
confuses the calling function about where its locals, etc, are.

Gould machines (i've heard) make it difficult to do alloca().  the MIPS
R2000 normally uses a virtual frame pointer.  various 68000 family
compilers (at least the GreenHills compiler and Ken Thompson's 2c) do
not use a register for a frame pointer, so they too probably have
trouble with alloca() in the general case.  many of these compilers
have compile time options to force using a register as a real frame
pointer, in order to allow alloca() and other stack munging.

>					    If C were to provide a means 
> to declare an automatic array with size that depended on an integer valued
> argument, many of the uses of alloca would disappear;  would this be any
> easier to implement than alloca?  Why?

yes, because that provides a way of telling the compiler that either it
needs a real frame pointer for some particular function, or at least that
some part of the stack frame is of variable length.  the gnu c compiler
provides this functionality.  not only is easier, but notationally it
is nicer, though not as general as alloca().

paul haahr
princeton!haahr or haahr@princeton.edu