eric%cit-vax@sri-unix.UUCP (07/01/83)
[4.1bsd VAX 11/780] I want to allocate dynamic arrays in such a way that they go away automatically when the procedure exits. Normally, I'd just use malloc and free the memory at the end of the procedure. However, this procedure can be interrupted (by ^C) causing a non-local goto (via setjmp/longjmp). The easiest way to do this is to write a routine "salloc" which allocates the space on the stack by decrementing SP and returning its new value. (Languages like ALGOL do this for you, array bounds can be variables). What I need to know is whether the C compiler mucks around with the stack pointer at times other than procedure linkage and local variable space allocation, i.e. at times other than procedure entry/exit. Does it, for example, change the stack pointer to allocate register spill space during complex expression evaauation? Does anyone know? Thanks. - Eric Holstege (eric@cit-vax) (...ucbvax!cithep!citcsv!eric)
mark.umcp-cs%udel-relay@sri-unix.UUCP (07/02/83)
From: Mark Weiser <mark.umcp-cs@udel-relay> Even if the compiler does mung with the SP, it should still be safe to allocate from it. Whatever the compiler does it should do from the current sp value, which is the one you updated to leave space for your array.
dan%bbncd@sri-unix.UUCP (07/05/83)
From: Dan Franklin <dan@bbncd>
The VAX 4.1BSD C compiler, like many C compilers, pushes arguments on the stack
as they are generated for a function call. Thus, salloc() will not work in:
foo(arg1, salloc(N), arg3);
Arg3 gets pushed on the stack, then salloc() is called and its return value is
pushed, then arg1, and finally foo() is called. But arg3 is far away from the
other arguments; foo() will never find it!
I couldn't make the VAX compiler use the stack for expression analysis; I
probably didn't make it complicated enough. This is a common strategy, though,
and if you think you might run the code on another system someday you should
avoid it. Simple assignment statements would probably work:
p = salloc(N);
on machines like the VAX and PDP-11. On at least one architecture I know of,
though, the compiler generates ALL references to local vars off sp; thus
salloc() would fail rather spectacularly no matter how you used it. Also, the
optimizer is no respecter of statement boundaries, so maybe even doing an
salloc() NEAR some function calls or complex expressions could screw up.
Personally, I think salloc() is too implementation-dependent to be worth it,
even though it would be incredibly useful.
Dan Franklinbob%ucla-locus@sri-unix.UUCP (07/06/83)
From: Bob English <bob@ucla-locus> If salloc acted on it's arguments rather than returning a value ( "salloc(n,&tmp);" instead of "tmp = salloc(n);"), it would rarely be swept (or written) into a complex expression. --bob--
tim@unc.UUCP (07/10/83)
Stack space can be allocated in C, if its size is known at translation time, by simply putting a declaration for the data at the head of a block. When the block is entered, the space is allocated, and when the block is left, the space is dealocated. This has the added advantage of accessing the data through a variable instead of a pointer, making for cleaner code. ______________________________________ The overworked keyboard of Tim Maroney duke!unc!tim (USENET) tim.unc@udel-relay (ARPA) The University of North Carolina at Chapel Hill
rcj@burl.UUCP (07/11/83)
The comment about it being OK to allocate from the SP is quite valid. (At least it used to be.) In college, we had a PDP-11/34 running V6. My introduction to C was in a mini-computers course where the instructor told us one day that we had two weeks to write a crude task scheduler to run on our PDP-11/03 (LSI-11). The only catch was that we had to write it completely in C, compile it into Unix Assembler, run it through an "ed" command file to translate it into MACRO-11, and run it without mucking with it on the LSI. This was bad enough for us poor innocent sophomores, but what made it even worse was that NONE of us knew C. When this was pointed out to the professor, he simply told us that the R&K book was $12.00 in the bookstore. We ended up implementing part of the code by initializing unsigned integer arrays with hardcode instructions for the LSI, and then calling the hardcode "routines" by doing a "goto array_name;". In the process, we allocated space backwards from the SP and used it with no problems. This also allowed us to access registers without having to use the "register" capability of C -- we weren't sure which registers C would use and were generally paranoid about C at the time; having had such in-depth study of it for such a long time :-) Ah, the good old days, -- The MAD Programmer -- 919-228-3814 (Cornet 291) alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcj
ka@spanky.UUCP (07/11/83)
My understanding is that allocating space on the stack by decrementing the sp is safe. The C compiler can push temporary values on the stack, but references to these are relative to the sp. Kenneth Almquist
lee.usc-cse%rand-relay@sri-unix.UUCP (07/13/83)
Yes, the compiler does use the stack during expression evaluation, tho if you do your "salloc" (which is provided is -lPW under the name amalloc) at statement level, there is no problem with the VAX or PDP/11 compilers. However, you are asking for portability problems because some C compilers make other assumptions about the stack pointer and may in fact be unable to deal with runtime changes to the stack frame size. I recommend against this under-the-compiler approach. -- Lee
gb@unc.UUCP (07/14/83)
On our 4.1BSD system, the command
find /usr/src/cmd -exec grep "\<alloca\>" "{}" \; -print
locates the following references to alloca.
-----------------------------------------------
* Note: because the routine "alloca" is not portable, TUBESIZE
cmd/ex/ex_tune.h
char *alloca(),*sp();
arglist = (int *) alloca((nargs + 1) * sizeof(int));
cmd/lisp/franz/eval2.c
char ch, *strb, strbb[BUFSIZ], *alloca(); /* temporary string buffer */
strb = alloca(count);
cmd/lisp/franz/lam5.c
register char *string; char *alloca();
string = alloca(count);
cmd/lisp/franz/lam6.c
char *sp(), *alloca();
work = (int *)alloca((top-bot)*2*sizeof(int));
cmd/lisp/franz/pbignum.c
int *sp(), *alloca(), d, negflag = 0, m, n, carry, rem, qhat, j;
qbot = alloca(toint(utop) + toint(vbot) - 2 * toint(ubot));
cmd/lisp/franz/divbig.c
char *strtbl,*alloca();
strtbl = alloca(strsize);
strtbl = alloca(strsize);
cmd/lisp/franz/ffasl.c
char *alloca(); /* stack space allocator */
string_core_org = alloca(string_size - 4);
binder_core_org = alloca(lit_end - bind_org);
cmd/lisp/franz/nfasl.c
char *alloca();
base = handy = (double *) alloca(count);
cmd/lisp/franz/vax.c
xcreat.c+s:char *alloca();
xcreat.c+s: d = alloca(size(name));
xmsg.c+s:char *alloca();
xmsg.c+s: str = alloca(size(file));
cmd/local/sccs/s4/FILES
char *alloca();
d = alloca(size(name));
cmd/local/sccs/s4/xcreat.c+s
char *alloca();
str = alloca(size(file));
cmd/local/sccs/s4/xmsg.c+s
char *alloca(); /* forwar decl */
v = ip = alloca(BUFSIZ);
v = ip = (int *) alloca(BUFSIZ);
cmd/local/sccs/com/dodelt.c+s
char *alloca(); /* forward */
xp = p = alloca(size(s));
cmd/local/sccs/com/pf_ab.c+s
---------------------------------------------
Gary Bishop
gb.unc@udel-relay
unc!gbarnold@gatech.UUCP (07/15/83)
The reason most people probably don't know about alloca in 4.1 BSD is that
it isn't documented anywhere (at least where 'normal' users would see it).
It is not mentioned on the man page with malloc and calloc, which is
the usual place to look.
it is also probably peculiar to Berkeley, and therefore not
portable to machines running Bell Unix (v7, sys 3, sys 5, or whatever).
(I mean using it is non-portable. I'm sure the code could be physically
moved to any Vax-Unix system.)
another reason is that most people don't go looking thru the libraries.
there is nothing wrong in doing so, it's nice to know what one has, but when
that is the only way to find a routine that's not documented, it's not
surprising that the routine is little known.
how 'bout it you folks at berkeley? if you're going to give us
neat routines like alloca, how about telling us about them? You still
have the chance with 4.2.........
--
Arnold Robbins
Arnold @ GATech (CS Net)
Arnold.GATech @ UDel-Relay (ARPA)
...!{sb1, allegra}!gatech!arnold (uucp)
...!decvax!cornell!allegra!gatech!arnoldguy@rlgvax.UUCP (07/17/83)
alloca() is a PWBism, and was supplied with PWB/UNIX 1.0 and the USG UNIX
releases (including System III and System V), and is used by the SCCS code,
among other clients. It seems to have crossed the blood-brain barrier and
passed into Berkeley UNIX, along with so many other things...
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guypdl@root44.UUCP (Dave Lukes) (07/18/83)
The only code I've seen using the infamous (and totally undocumented) alloca(), is SCCS (the Source Code Control System), which has an alloca() in it's own library (N.B. this is with System III, I dunno about BSD4.1 etc.) So, presumably, that's what the libc in 4.1 has an alloca() for. Dave "I hate alloca()" Lukes (...!vax135!ukc!root44!pdl)
jlw@ariel.UUCP (J.WOOD) (07/19/83)
I would recommend strongly against using undocumented routines from the C library. I have personal experience with letting one of the people in my group use an undocumented routine in USG Rel. 3 which disappeared, much to our chagrin, in USG Rel. 4. Joseph L. Wood, III ABI Holmdel (201) 834-3759 ariel!jlw
fuka@parsec.UUCP (07/19/83)
#R:sri-arpa:-269100:parsec:44200011:000:499
parsec!fuka Jul 11 17:17:00 1983
There is an apparently undocumented libc routine in 4.1 called alloca, which
seems to do exactly what you want. Here is the header information from
alloca.s:
# @(#)alloca.s 4.1 (Berkeley) 12/21/80
# like alloc, but automatic
# automatic free in return
I have never tried it, but discovered it one day while peering into the
recesses of the libc sources. Does anybody know which UNIX programs use it?
Kent Fuka
Parsec Scientific Computer Corp.
{allegra|ihnp4|uiucdcs}!parsec!fukaguy@rlgvax.UUCP (07/20/83)
Other way around; "alloca" was done as part of PWB/UNIX and was picked up
by Berkeley (like so many other things that have leaked out the back door...),
so it *is* available on PWB/UNIX 1.0 and System III (and possibly V). Just
look in /lib/libPW.a, unless the implementors of UNIX on that machine decided
they didn't want to bother with "alloca" and rewrote the SCCS and other code
not to use it.... The "-lPW" and "-lpw" libraries were probably written by
the PWB/UNIX folks, and used heavily by PWB-specific software like SCCS. I
don't know of any new software written with it (especially post-V7 software).
Since the libraries were changed for V7 (f'rinstance, Standard I/O was moved
to "-lc"), I suspect they decided to leave "-lPW" around (but canned "-lpw")
so nobody had to rewrite SCCS (it's OLD code and gives "lint" a coronary) but
decided it wasn't a real supported library and didn't document it; I think
"alloca" is in the PWB/UNIX 1.0 manual but it's not in the System III manual.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guyglenn@nsc.UUCP (07/20/83)
If you are interested in portability, _don't_ use alloca. Some
architectures make assumptions about how routine stack frames are
laid out that make it impossible to port this routine.
I ran across this problem when porting SCCS to our NS16000-based
system. When I first bumped into alloca, I thought it was a neat
idea. Then I tried to port it and discovered that, no matter how
I tried playing with the stack and frame pointers, there was no way
to maintain stack frame integrity so that subsequent function calls
would work. I ended up replacing invocations of alloca with malloc/
free pairs.
BTW: don't blame this routine on Berkeley. It shows up on USG systems
as part of libPW.a, almost certainly predating its appearances on
Berkeley systems.
-- Glenn Skinner
...!{fortune,menlo70}!nsc!glenntim@unc.UUCP (07/23/83)
It seems rather overly simplistic to say that you can't duplicate alloca on your system. You can't duplicate it with the same efficiency, perhaps, but there's no reason you can't use a dynamically-allocated stack. Since it is portable in this way, why should we refrain from using something that helps on our machines? ______________________________________ The overworked keyboard of Tim Maroney duke!unc!tim (USENET) tim.unc@udel-relay (ARPA) The University of North Carolina at Chapel Hill
pdl@root44.UUCP (Dave Lukes) (08/03/83)
Just a quickie (?!?): The System 5 SCCS DOESN'T use alloca at all !! (WOW !!!). (What next: soon people will be writing software that doesn't depend on the order of characters in a word (heh heh). Dave Lukes (...!vax135!ukc!root44!pdl)