Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!ark
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: scope of malloc
Message-ID: <11631@alice.att.com>
Date: 17 Nov 90 17:02:44 GMT
References: <1990Nov07.134942.7355@virtech.uucp> <3739@skye.ed.ac.uk> <4251@goanna.cs.rmit.oz.au>
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 26

In article <4251@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <3739@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes:
> > Are there *any* widely-used processors
> > that can't implement alloca() reasonably efficiently even with
> > compiler support?

> Any processor that can't implement alloca() as a built-in operation is
> going to have a hard time with PL/I, Fortran 90, and Ada, all of which
> allow the declaration of local variables whose size is not known until
> the declaration is elaborated.  The fact that gcc supports alloca() as
> well as "auto int foo[some_expr()]" is not a coincidence.

Quite true -- most C compilers will have a hard time compiling PL/I or Ada!

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.

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.

-- 
				--Andrew Koenig
				  ark@europa.att.com