Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!uflorida!travis!paulb From: paulb@ssd.csd.harris.com (Paul Beusterien) Newsgroups: comp.lang.c Subject: Re: scope of malloc Message-ID: Date: 19 Nov 90 22:50:46 GMT References: <1990Nov07.134942.7355@virtech.uucp> <3739@skye.ed.ac.uk> <4251@goanna.cs.rmit.oz.au> <11631@alice.att.com> Sender: news@travis.csd.harris.com Organization: Harris Computer Systems Division Lines: 18 In-reply-to: ark@alice.att.com's message of 17 Nov 90 17:02:44 GMT In article <11631@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. > > 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. Not necessarily. It may be possible to use one stack pointer all the time except for routines that use alloca. In the routines that call alloca, the performance gains of alloca more than make up for the overhead of using a second stack pointer for the frame. -- Paul Beusterien paulb@ssd.csd.harris.com Harris Computer Systems {uunet,mit-eddie,novavax}!hcx1!paulb Ft. Lauderdale, FL voice: (305) 973 5270