Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!rutgers!mit-eddie!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.lang.c
Subject: Re: alloca
Summary: variable (mutable) stack based allocations
Message-ID: <5082@killer.DALLAS.TX.US>
Date: 5 Aug 88 03:35:57 GMT
References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp> <19895@cornell.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 48

In article <19895@cornell.UUCP>, aitken@svax.cs.cornell.edu (William Aitken) writes:
> In article <8293@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
> >
> >The C vendors aren't evil (?) either; requiring support for alloca()
> >does impose an undue burden on implementations on some architectures.
> >
> 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?

The only reasonable way to allocate a variable amount of space from the
stack is to maintain a register (or local memory cell) containing the
size or end of the allocated space -- on some computers this is provided
"free of charge" by the architecture (so we use it) and on others it
imposes overhead on subroutine call/return linkage, usually serious only
for very short routines (and we do not use it).

A second and much more serious problem is that many of us are forced to
use Intel based boxes with 64K stacks and code using alloca() often
allocates too much local memory.  Malloc() on the other hand can always
allocate 64K per chunk and often (MSC under DOS for example) can allocate
any size up to the hardware available.  Of course, sloppy programmers then
have to remember to free what they allocated -- I find this can help document
the routine as well (named braces would help even more, oh well . . .).

>                                    ...   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?

See comments above:  both problems would remain (except that a mechanism
could probably be built into Intel C compilers to allcoate arrays off a
second "software" stack -- compilers for the 6502 often do this).

Does anyone know of an alloca() implementation that works this way -- other
than Doug Gwen's (and I would like to see it as well).

> 						---- Bill.

> William E. Aitken <aitken@svax.cs.cornell.edu>        (607)257-2542(h)
>   {uw-beaver,ihnp4,vax135,decvax}!cornell!aitken      (607)255-4222(o)
>   aitken@crnlcs.BITNET               700 Warren Rd. #20-2A, Ithaca, NY
>   42 26'30" N 76 29'00" W                              4148 Upson Hall


Charles Marslett
chasm@killer.dallas.tx.us
STB Systems, Inc.
(2140 234-8750