Path: utzoo!attcan!uunet!cs.utexas.edu!hellgate.utah.edu!cdr.utah.edu!moore
From: moore%cdr.utah.edu@cs.utah.edu (Tim Moore)
Newsgroups: comp.sys.hp
Subject: Re: alloca() on the HP9000/300
Message-ID: <1990Aug15.101314.9626@hellgate.utah.edu>
Date: 15 Aug 90 16:13:13 GMT
References: <1455@tub.UUCP> <1340135@hpclscu.HP.COM>
Organization: University of Utah CS Dept
Lines: 52

In article <1340135@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>>> [Is alloca() possible on HP machines]?

>> in which a function references its local and parameters off of the frame
>> pointer.  alloca() diddles the stack pointer and returns, hoping that no one
>> will notice, since all references are off a6 not a7, and a7 will be restored
>> on the unlk.

You could use gcc on your 300 series machine, where alloca is built in.

>And this is exactly why it is hard to make a "real" alloca() (whatever that
>is) work on an 800.
>
>The 800 does not have a separate frame pointer - every local variable,
>including parameters, is referenced off SP (the top-of-stack pointer).
>Changing SP thus has terrible consequences.
>
>I suppose it would be possible to build alloca() into the compiler itself
>(i.e. affect the code generation for a function based on whether it calls
>alloca() or not), but alloca() being so non-standard, it was decided not to
>do so.
>
>Now that the GNU C compiler has been ported to the 800 series, that would
>be a good place to try out such techniques, and evaluate them.

The 800 port of gcc also has built in support for alloca. gcc also uses
a frame pointer everywhere, for better or worse. Supposedly gcc 2.0
will have better support for not using a frame pointer, which can be
an important optimization.

>All in all, it's probably best to stay as far away from alloca() as
>possible. If you *have* to use alloca() (i.e. someone else's software, and
>you can't / won't change it), you can use some good PD alloca.c that does
>not fiddle with SP. The code generated will be no worse than if you
>actually modified the code to call malloc()/free().

There are all sorts of reasons why alloca is nice; the luxury of not
having to call free () is only one of them. Another feature is
automatic deallocation of storage on catching a signal or a longjmp.
While I don't really want to rekindle the alloca flames that appear
periodically in comp.lang.c, I would personally use alloca freely and
rely on compiler support, or the PD code for broken :-) machines that
don't support alloca.

>
>-----
>Shankar Unni                                   E-Mail: 
>Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
>Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar
Tim Moore                     moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters