mark@lakesys.UUCP (Mark Storin) (08/12/88)
Being new to programming the ST, could some kind soul please explain what the problems are with malloc on the ST? -- Mark A. Storin Lake Systems, Milw., WI UUCP: uwvax!uwmcsd1!lakesys!mark || uunet!marque!lakesys!mark
braner@batcomputer.tn.cornell.edu (braner) (08/13/88)
[] Use malloc() (lowercase m), the library function that came with your C compiler. Assuming you got a decent compiler (Laser, Megamax, MWC, etc) (I don't know about Alcyon) that will keep you out of trouble. Make sure you use free() for what was malloc()ed, not Free(). The only case where you need Malloc() (uppercase M, the GEMDOG function) is when you absolutely need to allocate more than 64K at once, since malloc() takes an unsigned int as its argument, and an int on the 68000 is (or should be) 16 bits. (Some compilers, like Lattice, use 32 bit ints on the 68000, with a major execution speed penalty.) The Malloc() GEMDOG function takes a long argument. Usually you can allocate large things in smaller pieces (e.g. a large matrix row by row, initializing a vector of pointers to rows as you go, and later accessing the matrix elements by double indirection -- which is faster than 2-d matrix access anyway!). Use Free(), not free(), for freeing up what was Malloc()ed. Actually Malloc() is not completely broken: you can use it a few times. Just don't call it more than a few (say 20) times in a row, and try not to call Free(). If you have to call Free(), then make sure you are Free()-ing things in reverse order of Malloc()-ing them. Malloc() was designed for the OS to allocate memory to programs that are loaded, possibly in a chain of Pexec()s. It was never designed for allocating a zillion little bits and pieces and freeing them in arbitrary order. It is too SLOW for those kind of applications anyway. That's where you need the _library_ function malloc(). It Malloc()s large chunks for you and manages the little pieces locally. - Moshe Braner
dinolt@wdl1.UUCP (George W. Dinolt) (08/16/88)
/ wdl1:comp.sys.atari.st / braner@batcomputer.tn.cornell.edu (braner) / 1:12 pm Aug 12, 1988 / [] M. Banner writes about Malloc: Use malloc() (lowercase m), the library function that came with your C compiler. Assuming you got a decent compiler (Laser, Megamax, MWC, etc) (I don't know about Alcyon) that will keep you out of trouble. Make sure you use free() for what was malloc()ed, not Free(). The only case where you need Malloc() (uppercase M, the GEMDOG function) is when you absolutely need to allocate more than 64K at once, since malloc() takes an unsigned int as its argument, and an int on the 68000 is (or should be) 16 bits. ... In fact the MWC compiler has an lmalloc(lsize) which takes a long as an argument, so in that compiler at least, there is no need to use Malloc. Regards, George Dinolt dinolt@ford-wdl1.arpa, ...!sun!wdl1!dinolt
leo@philmds.UUCP (Leo de Wit) (08/25/88)
In article <4120005@wdl1.UUCP> dinolt@wdl1.UUCP (George W. Dinolt) writes: [amongst other things]... >In fact the MWC compiler has an lmalloc(lsize) which takes a long as an >argument, so in that compiler at least, there is no need to use Malloc. It depends on where this lmalloc does its allocation. In Lattice C malloc also takes a long as argument (an int being 32 bits in Lattice). Because the heap is lying between bss and stack the available space for this malloc depends on what is allocated for the program at startup time (by Mshrink); for instance a 'sh', a 'make', a 'find', a 'time' do have to leave room for other programs to exec in. Then it can be profitable for a program to use both the system Malloc and the C library's malloc. I could however imagine a malloc that uses Malloc to reserve memory not currently owned by the program... A clever one can even hide some of the defiencies of the current Malloc (especially when it Malloc's in big chunks so that it doesn't have to be clever too often, as cleverness takes time 8-). Leo.
to_stdnet@stag.UUCP (08/30/88)
From: dal@syntel.UUCP (Dale Schumacher) [leo@philmds.UUCP (Leo de Wit) writes...] > In article <4120005@wdl1.UUCP> dinolt@wdl1.UUCP (George W. Dinolt) writes: > [amongst other things]... >>In fact the MWC compiler has an lmalloc(lsize) which takes a long as an >>argument, so in that compiler at least, there is no need to use Malloc. > > It depends on where this lmalloc does its allocation. In Lattice C > malloc also takes a long as argument (an int being 32 bits in > Lattice). Because the heap is lying between bss and stack the > available space for this malloc depends on what is allocated for the > program at startup time (by Mshrink); for instance a 'sh', a 'make', a > 'find', a 'time' do have to leave room for other programs to exec in. > Then it can be profitable for a program to use both the system Malloc > and the C library's malloc. This is one problem with malloc()ing from a fixed heap area in the middle of the program's memory space. For those who aren't familiar with it, this is a rough picture of a running C program's memory map. low memory _______________________________ base |basepage (a.k.a. the TPA) | |-------------------------------| |text (executable code) | |-------------------------------| |data (initialized data) | |-------------------------------| |bss (uninitialized data, zero) | |-------------------------------| break |heap | | | V | | : | | ^ | |stack | | |_______________________________| end of program space high memory The stack grows toward the heap, and the heap is usually allocated by calls to malloc(). This means Malloc() is not used for dynamically allocated space within the program. One problem with this scheme is that the program must know at startup how much space it will need for it's heap. Also, any space reserved for heap cannot be used by other programs executed from within this program. And finally, there may be PLENTY of free memory still available in the system (throuh Malloc()), but when you're out of heap, you're out of memory. > I could however imagine a malloc that uses Malloc to reserve memory not > currently owned by the program... A clever one can even hide some of > the defiencies of the current Malloc (especially when it Malloc's in > big chunks so that it doesn't have to be clever too often, as > cleverness takes time 8-). The dLibs malloc()/lalloc() functions do this. A global variable, which defaults to 64K allows the programmer to set the "granularity" of the calls to Malloc(). Calls to malloc()/lalloc() allocate a series of "heaps", each at least the grain size (lalloc() may specify a block bigger than the grain size) from which subsequent malloc()/lalloc()s are satisfied, with only 4-bytes of overhead per memory block. I've used these routines in a MicroEMACS implementation (which malloc()s each line) and never had a problem, even when adding/moving/deleting large amounts of text. In addition, this scheme allows almost ALL of unallocated memory to be used by programs executing from within another program. Allocation from the heap is also available, through brk()/sbrk(), and another global variable defines the size of the heap/stack area. Best of all, the source code for these routines is part of the public domain dLibs C runtime libraries. -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104 ...pwcs!stag!syntel!dal United States of America "Man who says, 'It cannot be done', should not interrupt man who is doing it." -Ancient Chinese Proverb