Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!STONY-BROOK.SCRC.SYMBOLICS.COM!jrd From: jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) Newsgroups: comp.sys.atari.st Subject: Re: gcc problems Message-ID: <19880918171113.7.JRD@MOA.SCRC.Symbolics.COM> Date: 18 Sep 88 17:11:00 GMT References:Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 94 Date: 9 Sep 88 03:34:23 GMT From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net (Simon Poole) In article jeff@stormy.atmos.washington.edu (Jeff Bowden) writes: >I grabbed the gcc executables a few days ago. I found that I had >insufficient resources to run it (sob :-( ). Gcc can be run on a 1 MB machine! You will not be able to compile any larger files from GULAM, but you can revert to compiling from the Desktop if memory is a problem. To bootstrap you NEED: a copy of gulam a diskeditor 1) patch the executable of gcc-cc1.ttp so that only 300 kB of stack instead of 500 kB are allocated (you can search for the value 500000, it only occurs once, somewhere around 364kB). Yah, that's described in the blurb. In fact, 300000 is still far more than you need; in my experience, 128K is plenty for most things. The thing that really eats stack is compiling large hairy functions is -O; the 500000 value is for compiling the instruction-cracking routing in GAS. If you can live without -O, 64K or maybe even 32K will be enough. [That you have to do this is really a bug, there is NO need for a GEMDOS only program, that doesn't exec another program to give memory back to GEMDOS, I'm changing my crt0 so that it will take -1L in _stksize to mean: "Don't do a Mshrink"] Careful; memory that is malloc'ed comes from ABOVE the stack, not below it, so you really do want to keep the stack at the smallest value that works for you. 2) Now throw all resident stuff out (accessories etc. just keep GEMBOOT or folderxxx (you do have a HD?)), start gulam and setup the enviroment as described by jrd. You should now be able to compile most programs (you can compile all of flex except parse.c and scan.c for an example). This is a good time to get the sources and extract the documentation from them, how else are you going to know about -mshort -fomit-frame-pointer etc.? Right. If there's sufficient demand, I'll package up the docs separately; or someone else with more time could do so... hint hint... 3) If a source file is too large to be compiled from GULAM, you will get a "no more virtual memory" message or someting like that (probably already from gcc-cpp). typically from gcc-cc1, actually... You can workaround this by running the compiler from the desktop, the current gcc.ttp will NOT work from the desktop (reasons follow), so you will have to write a small wrapper program to do this (I'm fixing gcc.ttp right now.....). Note: all gcc stuff assumes: file-handle 0 = stdin 1 = stdout 2 = stderr since the GEMDOS default for handle 2 is the serial port, this isn't much good when you start stuff from the desktop. Yah, I've since realized that 2 is the serial port (!). If you fix std-init, would you post the fixed version? Also, does anyone out there have a description of what file numbers 'default' to what? So you need a Fforce(2,Fdup(1)) At the begining of your program to see any error output (and due to a bug in stdio to see any output at all). Trying this shows two bugs in the current runtime library: - Fforce has a wrong binding in osbind.h, it uses 3 short (aka 16 bit) arguments! Write a trap-1www function to do this. [BTW is anybody working on cleaning up the library, there is a lot of stuff that should be done] No kidding. As I said in the doc, the library is pretty ragged. I'm working on getting rid of the trap_foo functions, and generating the traps in line; perhaps it makes sense to post a recompiled library whe that happens? [...] Don't get put off by this description, GNC CC is worth it! Glad you like it.