🚀 go-pugleaf

[Seems as something zapped this the first time, sorry if it shows up twice]

In article <JEFF.88Sep2035059@stormy.atmos.washington.edu> 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). [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"]

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.?

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). 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.

		   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]

		      - stdout uses GEMDOS handle 2 instead of 1
			(I haven't actually found the location of the
                        bug yet, but the symptoms are (every thing
			from the desktop naturally.....):

		        Works:

			Fwrite(1,.....
		        Fforce(2,Fdup(1));
			Fwrite(2,.....

			Doesn't work (first line doesn't get output):

			fprintf(stdout,"%s\n","Test of stdout");
			Fforce(2,Fdup(1));
			fprintf(stderr,"%s\n","Test of stderr");

			Works:

			Fforce(2,Fdup(1));			    
			fprintf(stdout,"%s\n","Test of stdout");
			fprintf(stderr,"%s\n","Test of stderr");

Don't get put off by this description, GNC CC is worth it!
(For the Turbo C people, there is a note in the manual about
using registers for parameter passing in future versions......)

-- 
----------------------------------------------------------------------------
UUCP:   ...mcvax!cernvax!forty2!poole			Simon Poole
BITNET: K538915@CZHRZU1A
----------------------------------------------------------------------------