Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc01!hpcuhb!hpcllla!hpclisp!hpclscu!shankar From: shankar@hpclscu.HP.COM (Shankar Unni) Newsgroups: comp.sys.hp Subject: Re: alloca() on the HP9000/300 Message-ID: <1340135@hpclscu.HP.COM> Date: 14 Aug 90 03:14:12 GMT References: <1455@tub.UUCP> Organization: Hewlett-Packard Calif. Language Lab Lines: 40 > >Is it possible to write a "real" alloca() for the HP at all, or is > >there some sort of conflict with the C compiler (i.e. does the way > >the stack pointer is handled make usage of alloca() impossible)? > > The conventional alloca() depends on the frame pointer / stack pointer model, > 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. 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. 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(). ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar DISCLAIMER: This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.