ramani@modesty.Stanford.EDU (Ramani Pichumani) (08/31/89)
Does anyone have a real working version of alloca(3C) for the MIPS compiler? I'm using a Silicon Graphics 4D R2000 box which doesn't come with alloca() in its library. Doug Gwen's semi-portable version won't do for my application since I truly need to extend the stack. I'm aware that the use of alloca() is discouraged because it is compiler and machine dependent. Yet all the Berkeley UNIX machines I've used seem to have it. And besides, allocating memory locally seems like a very convienent way of cleaning up garbage that is local to a procedure. Furthermore, dynamically allocated local memory can ease fragmentation problems with the heap. I've been told by one source that alloca() can't be truly implemented on a MIPS compiler because of the way it handles it's stacks. I hope this isn't the case. Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
sah@gumby (Steve Hanson) (09/01/89)
In article <11601@polya.Stanford.EDU>, ramani@modesty (Ramani Pichumani) writes: > >Does anyone have a real working version of alloca(3C) for the MIPS >compiler? I'm using a Silicon Graphics 4D R2000 box which doesn't >come with alloca() in its library. Doug Gwen's semi-portable version >won't do for my application since I truly need to extend the stack. >I'm aware that the use of alloca() is discouraged because it is >compiler and machine dependent. Yet all the Berkeley UNIX machines >I've used seem to have it. And besides, allocating memory locally >seems like a very convienent way of cleaning up garbage that is local >to a procedure. Furthermore, dynamically allocated local memory can >ease fragmentation problems with the heap. > >I've been told by one source that alloca() can't be truly implemented >on a MIPS compiler because of the way it handles it's stacks. I hope >this isn't the case. > >Ramani Pichumani Tel: (415) 723-2902 or 723-2437 >Department of Computer Science Fax: (415) 725-7411 >Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu >Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani alloca has been implemented as a built-in operator in the upcoming 2.10 compiler when alloca.h is included, otherwise you will get the portable version. The following is taken from alloca.h: ------------------------------------------------------------------------------- /* --------------------------------------------------- */ /* | Copyright (c) 1986 MIPS Computer Systems, Inc. | */ /* | All Rights Reserved. | */ /* --------------------------------------------------- */ /* $Header: alloca.h,v 1.1 89/07/19 17:29:15 lai Exp $ */ #ifndef __ALLOCA_H #define __ALLOCA_H /* ** Synopsis ** #include <alloca.h> ** void *alloca(integral_types); ** ** Description ** This header is to be included if the built-in version ** of alloca is desired. The built in version is more ** efficient than the libc version, but it is less ** flexible. The built-in version is implemented as an ** operator and can only be applied to integral_types. ** integral_types are comprised of type char, the signed ** and unsigned integer types, and the enumerated types. ** See also alloca(3). */ #define alloca __builtin_alloca #endif ---------------------------------------------------------------------------- Less flexible means it can't be assigned or its address can't be taken. --
net@tub.UUCP (Oliver Laumann) (06/12/90)
Does anybody know whether there exists a version of alloca() for MIPS CPUs? I mean the `real thing', i.e. an alloca() that actually advances the stack pointer, not a quiche-eater alloca() that uses malloc() and free(). I'm in the process of porting a piece of software that requires alloca() (I'm sure at this point you have already guessed what software package I'm speaking about :-) to a Sony workstation which has a MIPS R3000 CPU. Unfortunately, the version of alloca() in Sony's libc.a looks like it's derived from the semi-portable alloca() written by Doug Gwyn (it uses malloc/free). Thanks, -- Oliver Laumann net@tub.cs.tu-berlin.de net@tub.UUCP
meissner@osf.org (Michael Meissner) (06/14/90)
In article <1371@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: | Does anybody know whether there exists a version of alloca() for MIPS CPUs? | I mean the `real thing', i.e. an alloca() that actually advances the stack | pointer, not a quiche-eater alloca() that uses malloc() and free(). | | I'm in the process of porting a piece of software that requires alloca() | (I'm sure at this point you have already guessed what software package | I'm speaking about :-) to a Sony workstation which has a MIPS R3000 CPU. | Unfortunately, the version of alloca() in Sony's libc.a looks like it's | derived from the semi-portable alloca() written by Doug Gwyn (it uses | malloc/free). You could always use GNU C, and #define alloca to be __builtin_alloca (many programs already have the necessary magic in them). Though of course, if you want to debug with the released GCC, you are currently up a creek. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so