Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!jarthur!nntp-server.caltech.edu!tll
From: tll@nntp-server.caltech.edu (Tal Lewis Lancaster)
Newsgroups: comp.sys.amiga.programmer
Subject: > SAS gripes (was DICE vs GCC)
Message-ID: <1991Apr5.173845.4404@nntp-server.caltech.edu>
Date: 5 Apr 91 17:38:45 GMT
References: <9104021420.AA10848@thunder.LakeheadU.Ca> <1991Apr4.034920.16298@marlin.jcu.edu.au> <1991Apr4.180217.19773@nntp-server.caltech.edu> <1991Apr5.030228.28756@marlin.jcu.edu.au>
Organization: California Institute of Technology, Pasadena
Lines: 72

cpca@marlin.jcu.edu.au (Colin Adams) writes:

 [cut...snip]


>I wouldn't say gcc is bug free but I have
>>found it more stable for my project than SAS or Aztec.   And I have been
>>producing 1.4 M executables with it!  So I wouldn't say gcc can't handle large
>>projects.

>yes, 1.4M executable is bigger than my small 250k exec. but I'm working
>to get it smaller not bigger :-)

yes, I hope to get that 1.4M down down a little bit too.  Maybe closer to 600K.

>  Because I am doing things that just can't be done with SAS or Aztec.

>Why not?

Well the main reason is I am creating object files greater than 32K (actually
some are around 80K).  SAS and Aztec can not handle object files > 32K.  Or to
be more precise a function call to another function in the same object file must
be < 32K apart.

Gee, why don't I just make object files < 32k (in other words write smaller C
files)?  Well I am not the one producing the C files, my computer is.  I have
been working on a compiler that uses C as the intermediate langauge and it is
the output from this compiler that is producing these large C files.  To make
the compiler produce smaller C files will mean a lot of changes to it.  I will
need to make these changes sometime...

>>SAS does have one of the better debuggers I have seen.  But its other tools
>>are geared more for small projects.  For example its make is really stupid
>>and forces duplication.

>The SAS debugger is pretty good. I have found the make utility to be
>ok, once you set it up it works fine. 

For example, if you have the following dependency

fish.o:  spam.h


LMK will try to compile spam.c.  So you are forced to use

fish.o: fish.c spam.h

Also, if you have the macro

OBJ=  [ lots of files total length > 255]

and try 

fish: $(OBJ)
	blink FROM $(OBJ) ...

This will lock up your computer and maybe even trash your hard-drive.
So you are forced to duplicate the contents of OBJ into a blink file.

>Still SAS is good enough for me.

Yes, I have to agree SAS is pretty good.  I am just pointing problems with it
that prevent me from considering it as a professional product.

>-- 
>Colin Adams                                  
>Computer Science Department                     James Cook University 
>Internet : cpca@marlin.jcu.edu.au               North Queensland
>'And on the eight day, God created Manchester'

Tal Lancaster
tll@tybalt.caltech.edu