ted%nmsu.csnet@relay.cs.net (06/05/88)
The 4.3 manual entry for alloca says:
BUGS
Alloca is both machine- and compiler-dependent; its use is
discouraged.
On the other hand, alloca is often used and strongly supported by the
gnu camp (n.b. heavy use in emacs and bison).
It is true that proper use does simplify many aspects of avoiding hard
limits for things like line lengths and such. Alloca is also very
handy in implementing stack gaps so that setjmp/longjmp can be used to
do a weak implementation of coroutines and lightweight processes.
It is also true that alloca is almost trivial to implement on most
machines (say with a macro which expands to a single machine
instruction to in(de)crement the stack pointer).
What is the opinion of the masses? Is alloca really such a problem
across differing architectures? Is it really that useful?gwyn@brl-smoke.UUCP (06/05/88)
In article <16018@brl-adm.ARPA> ted%nmsu.csnet@relay.cs.net writes: >What is the opinion of the masses? Is alloca really such a problem >across differing architectures? Is it really that useful? Yes, alloca() simply cannot be reasonably implemented on a large class of C implementations (notably, those with linked procedure context frames instead of a single stack). I published a public- domain "mostly portable" version that works on all stack-based implementations, but it uses malloc() for the allocation, not the stack. Many stack-based implementations do not supply much stack space. In fact, Gnu seems to provide my alloca() for use on systems that don't come with their own. For a limited class of applications, alloca() can be useful. However, I don't use it myself. My applications all use a more disciplined approach to memory allocation.
henry@utzoo.uucp (Henry Spencer) (06/08/88)
> ... Is alloca really such a problem across differing architectures?
Yes; there are architectures on which it is very difficult to implement
efficiently. Stallman appears to have a mild case of the "all the world's
a VAX" syndrome: he cares about portability only when it doesn't get in
his way.
--
"For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henryjohn@frog.UUCP (John Woods) (06/09/88)
In article <16018@brl-adm.ARPA>, ted%nmsu.csnet@relay.cs.net writes: > The 4.3 manual entry for alloca says: > BUGS > Alloca is both machine- and compiler-dependent; its use is > discouraged. > On the other hand, alloca is often used and strongly supported by the > gnu camp (n.b. heavy use in emacs and bison).... > It is also true that alloca is almost trivial to implement on most > machines (say with a macro which expands to a single machine > instruction to in(de)crement the stack pointer). > What is the opinion of the masses? Is alloca really such a problem > across differing architectures? Is it really that useful? Architecture is not the only problem, as the manual entry hints; many compilers make alloca() impossible to use. What's more, it's GOOD that they do so: many optimizing compilers pull stunts with the stack like not resetting the stack pointer after each function call, so as to save time. Others dispense with a frame pointer entirely, because they "know" where the stack pointer will be in relation to the hypothetical frame pointer, and just index off of it appropriately. Some even do both. Slowing down every single program just so a couple of programs can be written without paying attention doesn't seem the best of tradeoffs. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu No amount of "Scotch-Guard" can repel the ugly stains left by REALITY... - Griffy
leo@philmds.UUCP (Leo de Wit) (06/10/88)
In article <16018@brl-adm.ARPA> ted%nmsu.csnet@relay.cs.net writes: > >The 4.3 manual entry for alloca says: > > BUGS > Alloca is both machine- and compiler-dependent; its use is > discouraged. > >On the other hand, alloca is often used and strongly supported by the >gnu camp (n.b. heavy use in emacs and bison). > >It is true that proper use does simplify many aspects of avoiding hard >limits for things like line lengths and such. Alloca is also very >handy in implementing stack gaps so that setjmp/longjmp can be used to >do a weak implementation of coroutines and lightweight processes. > >It is also true that alloca is almost trivial to implement on most >machines (say with a macro which expands to a single machine >instruction to in(de)crement the stack pointer). > >What is the opinion of the masses? Is alloca really such a problem >across differing architectures? Is it really that useful? The masses (at least one of them 8-) give their opinion: When you need local variables whose sizes cannot be determined at compile time, I think alloca() is ideal. Even when it is implemented as a function instead of inline code, it will outspeed malloc() by orders of magnitude (I think; BSD malloc is pretty nice though). (As for your single machine instruction, the value of the new stack pointer has also to be taken. But I will settle for 2). Besides, no more need of free; several modern architectures will restore the stack pointer using the frame pointer. The lack of dynamic arrays in C could be partly removed by using alloca(). Also linked lists can benefit from it. The drawback is that you still have to save things in global/static var's or on the heap when you want the function to return (a pointer to) such a value. Taking the MC68000 as an example: If compilers follow the convention to address parameters by a positive offset from the link pointer, the local variables by a negative offset, and temporaries by an offset from the stack pointer (and most do that), and always use LINK/UNLK instructions to build/undo the stack frame, it works. However, the last 'always' is not true; several compilers do not generate these instructions if the function has no local variables; they use stack pointer relative addressing then to reach the parameters (saving a few instructions). In this case it is impossible to determine the position of the stack pointer when the function was called, as it is not saved and it is modified by alloca(); unless someone makes a very clever alloca that keeps track of return addresses and lets the calling function return to it (alloca) when it (the caller) has done (for instance; I'm just philosofing); but I doubt if it can be done without breaking existing code, and if it can be done for each machine/compiler. The problem with alloca() also is that, just because it does not come in pairs (like malloc() - free()) and some (or most ??!?) compilers) cannot support it (see above for some reasons) it is not portable. But I have a nice alternative: lets always use alloca() and a new function, call it freea(), in pairs. Freea() should be called before leaving the function (although it does not need to be in this case). For the compilers that support alloca(): #define freea() /* a dummy */ For those that don't: #define alloca malloc /* the oldies */ #define freea free In both cases memory is allocated dynamically and freed upon return from the function. Everybody happy ? Leo.
jack@cwi.nl (Jack Jansen) (06/11/88)
I think alloca() should be implementable on all architectures, even those with a 'virtual stackpointer' (i.e. those where the compiler knows that the stackpointer will always be fp+NNN (or the other way around, for that matter)). I trick I once used was to allocate the memory on the heap, allocate two extra words, use one of them to build a linked list of all alloca-blocks within the scope and (here comes the trick) store the original return address in the other one, and replace the return address by the address of a routine that will free alloca() blocks and then really return. The only problem is setjump/longjump, but these can probably be massaged to handle the alloca blocks. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
pinard@odyssee.UUCP (Francois Pinard) (06/14/88)
In article <1988Jun7.170246.15101@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > > ... Is alloca really such a problem across differing architectures? > > Yes; there are architectures on which it is very difficult to implement > efficiently. Stallman appears to have a mild case of the "all the world's > a VAX" syndrome: he cares about portability only when it doesn't get in > his way. I've the feeling that you are not completely fair. Stallman made clear choices for the GNU project, and portability in itself is not an real issue. In the context of GNU, to "think portable" and "write portable" may help to see and understand aspects of one given problem, solutions that are portable may even be interesting in themselves because they are sometimes more general and more clear. But if portability gets in the way, it is put aside, simply. These choices are not new, they are well documented inside the GNU project. Stallman, to my own way of seeing things, contributed a lot and in several ways to the programming community. Alas, I often have the impression that a lot of people are simply standing around, crying for "more!, more!". This is not the best way to help. -- ------------------- --------- ------------------------------------------ Francois Pinard "Vivement C.P. 886, L'Epiphanie (Qc), Canada J0K 1J0 pinard@odyssee.uucp GNU!" (514)588-4656; Odyssee R.A.: (514)279-0716 ------------------- --------- ------------------------------------------
scs@athena.mit.edu (Steve Summit) (06/17/88)
I generally shy away from "edge of the envelope" functionality,
even if documented and "official": like right-of-way rules, the
"official"ness doesn't help you much when you get burned.
I've used alloca exactly once, and I submit that I had no
alternative: it was exactly the right thing to use for allocating
the space for the local variables of the function being
interpreted by a C interpreter I wrote once. An explicit
malloc/free wouldn't do, because of the possibility that the
function being interpreted could call longjmp...
Steve Summit
scs@adam.pika.mit.edumouse@mcgill-vision.UUCP (der Mouse) (06/22/88)
In article <500@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: > But I have a nice alternative: lets always use alloca() and a new > function, call it freea(), in pairs. > For [compilers] that don't [support alloca]: > #define alloca malloc /* the oldies */ > #define freea free Then why bother with alloca, if the semantics are such that malloc can be used instead? > Everybody happy? No. The people who use alloca to get automatic freeing on a longjmp (or other stack unwind) won't be able to tolerate the malloc replacement. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu