jeff@jplpub1.UUCP (03/25/87)
Now that Richard M. Stallman and the Free Software Foundation have released the first beta test of GCC (Gnu C), is anyone working or planning to work on a port to the Atari ST? The software is available via anonymous FTP from my machine, btw. Internet address is 128.149.1.8, just in case. ~ftp/earle/gcc.tar.Z: ...1054128 Mar 23 22:34 gcc.tar.Z Hmmm..a CRIPPLED ACCOUNTANT with a FALAFEL sandwich is HIT by a TROLLEY-CAR.. Jeff Skaletsky Jet Propulsion Laboratory System Engineering Group Computing and Communication Network Support Services Try these: jeff@jplpub1.JPL.NASA.GOV seismo!cit-vax!elroy!jplpub1!jeff elroy!jplpub1!jeff@csvax.caltech.edu jeff@jpl-milvax.ARPA Mail: 464 W. Woodbury Rd. Altadena, CA 91001 Phone: (818)354-7677
jdg@elmgate.UUCP (03/28/87)
In article <3450@elroy.Jpl.Nasa.Gov> jeff@jplpub1.jpl.nasa.gov (Jeff Skaletsky) writes: >Now that Richard M. Stallman and the Free Software Foundation have >released the first beta test of GCC (Gnu C), is anyone working or >planning to work on a port to the Atari ST? >Jeff Skaletsky >Jet Propulsion Laboratory Just a quick overview of the compiler seems to indicate that porting GCC will NOT be a trivial (nor possibily 'doable') task. It's sprinkled with alloca 's and comsumes 'huge' amounts of memory when optimizing. Sprinkle in one or two 68000 code generation err's and you begin to get the picture. STill it may have tons of code that is 'modifiable' to get 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. -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?
apratt@atari.UUCP (03/30/87)
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 \----------------------------------------------/
jdg@elmgate.UUCP (04/04/87)
In article <689@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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 >.................. >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 >\----------------------------------------------/ Allan I'm sorry, but I thought I *WAS* being fair. Allan I'm not pointing a finger at you (although I am pointing it at Atari). Atari (not you) sold me ^&%^% for an OS. I keep it simply because there is no way for me to ever get what I spent back. This is normal. But tell your boss if he had decided to release a *MINIMALLY TESTED* product, instead of trying to steal CBM's thunder, he'd get alot more user to user recommendations and alot more repeat business. Most of the people here on the NET know something about computers. Many recommend them to others. You can't gloss over statments like 'well it wasn't intend to allocate user memory'. It a bug. A bad one, just like 40 folders. One that should NEVER have gotten out the door. People get fired for bugs like that in shipping products (or at least demoted). It'll wash on CIS but not here........... -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?