Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!cae780!amdcad!sun!imagen!atari!apratt
From: apratt@atari.UUCP
Newsgroups: comp.sys.atari.st,comp.emacs
Subject: Re: GCC: Anyone working on a port?
Message-ID: <689@atari.UUCP>
Date: Mon, 30-Mar-87 14:08:00 EST
Article-I.D.: atari.689
Posted: Mon Mar 30 14:08:00 1987
Date-Received: Fri, 3-Apr-87 00:43:31 EST
References: <594@elmgate.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 25
Xref: utgpu comp.sys.atari.st:2465 comp.emacs:727

in article <594@elmgate.UUCP>, jdg@elmgate.UUCP (Jeff Gortatowsky) says:
> it working on a non-UNIX no-MMU system.....  but lots of it needs
> changing.  Remember the ST is FAMOUS for it's horrible memory allocation
> routines and this compiler seems to love choking down memory.

Please be fair: The ST does have some problems with the GEMDOS routine
Malloc, but once your program (i.e. gcc) is running, you own all of the
largest free block of memory in the system.  Your stack pointer is at
the top of this block, and your text+data+bss are at the bottom.
Memory allocators like malloc (that's little-m, as in a library
routine, not a system call) manage the memory between the end of your
bss and your stack pointer.  This can be upwards of 3/4 Mbyte in a 1040
without a RAMDISK.  If your library routines are buggy, it isn't
Gemdos's fault.  In the case of the Alcyon C compiler, malloc and free
work very well, and form one of the really useful and bulletproof parts
of that library.  Too bad malloc only takes an int size argument...

My point is that the system call Malloc is not intended for generalized
memory management, but rather for system-level allocations for process
TPAs and the like.

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/