Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!markv From: markv@kuhub.cc.ukans.edu Newsgroups: comp.sys.amiga.programmer Subject: Re: AmigaGCC stack hogging Message-ID: <28410.27afc63c@kuhub.cc.ukans.edu> Date: 6 Feb 91 15:02:52 GMT References: <1882f287.ARN1979@moria.UUCP> <1991Jan14.212254.9779@csun.edu> <18887df5.ARN1ad7@moria.UUCP> <1991Jan17.141218.19953@zorch.SF-Bay.ORG> <390@vixen.uucp> Organization: University of Kansas Academic Computing Services Lines: 61 > In order to have alloca()'ed memory automatically disappear at function > exit it either needs to be incorporated into the current stack frame, as it > commonly is on unix, or you need some sort of hook that can reliably be > called whenever the function exits. Such a hook exists in gcc, the config > headers for gcc allow you to define function prologue and epilogue code > that is generated at the beginning and end of every function. It seems to > me that this is the place to hook in an alloca()-like scheme which actually > does malloc()-like allocations. > > It should be fairly simple to do with some code like the following: > ...extensive and nice code managing a memory list... Rather than roll all this yourself, how about AllocRemember() and FreeRemember(). Have each function have a hidden variable in the prologue that gets initialized to NULL (the RememberKey), then use it. At function exit call FreeRemember() with key and it all goes away. struct Remember *FuncKey = NULL; #define alloca(x) AllocRemember(x, 0L, &FuncKey) Then at exit just call FreeRemember(&FuncKey, TRUE); For more details, look in the RKMs under Misc. Intuition functions. > The calls to push_alloca() and pop_alloca() would be automatically > generated as part of the FUNCTION_PROLOGUE and FUNCTION_EPILOGUE macros > which are defined in the tm.h header file in gcc, preferably conditional > on a run-time switch. > > This example code is in C, but if implemented would probably be done > in assembler for efficency. The call to push_alloc() could even be replaced > by an inline add if the nesting variable is made global. You could > probably get a performance increase by using AllocMem() rather than malloc, > but you'd have a memory leak if the program didn't exit by returning from > main() (ie by calling exit()). Also, setjmp/longjmp would cause problems. Huh? There is no difference in C level cleanup between returning from main() and exit(). (abort() is a different matter though). Note that a cleanup function could be defined and installed with atexit(). setjmp() longjmp() would still be problematic. However, one could slightly redefine the AllocRemember() call to a macro that also stuffed the Remember key in a static holder. AllocRemember() has very good performance. It only uses a singly linked list. It takes a pointer to a pointer because it always links onto the head of the list, so it doesn't have to traverse to the end. > Anyway, that's my suggestion for a workaround for gcc's stack gluttony. > Others are welcome to build on it. Personally, I generally run a version > of gcc on my Sun which cross-compiles for the Amiga, so it doesn't present > much of a problem for me. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~