Path: elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!ux2.cso.uiuc.edu!sink
   From: e-sink@uiuc.edu (Eric W. Sink)
   References: <29848@castle.ed.ac.uk>
   Originator: sink@ux2.cso.uiuc.edu
   Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
   Reply-To: e-sink@uiuc.edu
   Organization: University of Illinois at Urbana
   Distribution: comp
   Date: Tue, 29 Dec 1992 23:26:02 GMT
   Lines: 70

   Can't resist a few comments on this one:

   ngse18@castle.ed.ac.uk (J R Evans) writes:

   >Language implementations for the Mac, free of restrictions, are a little
   >thin on the ground when compared with other platforms.  Although gcc has
   >been ported to the Mac, it requires the proprietory MPW environment.  
   >Eric Sink offered his 'Harvest C' to the community some months back,
   >but himself describes it as an inappropriate line of development, and
   >has encouraged hackers to concentrate their efforts through the TopSoft
   >group on providing an unfettered environment for gcc, using the Harvest
   >user interface as a starting point.

   Minor point: actually it is not the user interface which is viable
   from Harvest C, it is the linker, and maybe the assembler.  You could
   use the GUI too if you liked, but that's not the hard part to rewrite.

   [ Why not Sozobon C ? ]

   >Unlike Harvest C, which by its author's statements needs
   >substantial further debugging, Sozobon C has gone through several stages
   >of refinement and produces workmanlike code (e.g. it can compile itself
   >reliably).

   >I suspect that a port to the Mac is not too horrendous a job, and I spent

   Perhaps bigger than you might think.  Early versions of Harvest C could
   self-compile reliably too.  Those version were on par with Sozobon
   in features: simple C compilation with no special support for Mac
   compilation.  THEN, I added Mac A5 globals, support for pascal functions,
   and so on.  THEN, you need a way to link.  What object files are you
   going to generate, and what will link them ?  Back to compilation,
   what about traps ?

MacMINIX uses a standard K&R C compiler that doesn't know anything about
using A5 as a globals pointer or about pascal functions.  This compiler
can be used to generate Mac applications.  Traps are called through glue
routines that convert the C calling conventions into Pascal calling
conventions and setup register A5 from a global variable before actually
calling the trap.  Global variables are not relative to A5, but absolute
addresses that are relocated when the program starts.  Subroutines are
not called through jump tables but through absolute addresses, also
relocated at program startup.  Mac applications generated with this
compiler have a special CODE 0 resource which contains 1 jump table
entry which loads and calls the main program which relocates itself
before referencing any global variables.  I have used these techniques
to build mac applications on a sun using gcc.  I don't think that
we are very far from a free development system for the mac.  It
will certainly not be as convenient as Think C, but what can we expect
for free.

   >So given that we can have a basic small compiler running quickly, just how 
   >big a job might it be to make this produce Mac code?  Comments sought!
   >[e.g. Sozobon doesn't know about the specialised purposes assigned within 
   >the Mac to A5, but apart from telling the compiler to leave A5 alone, 
   >I guess most of this stuff will appear in the libraries? Is that so? -- 
   >As is probably obvious, I've done comparitively little Mac programming.]

   Lots of work.  Actually producing the assembler instructions for C code
   is the "easy" part.  Turning all that into a Mac application is much
   harder.

   >Just in case anyone runs away with the idea that *I* might produce
   >such a compiler, let's say here and now that I don't have the time --

   bummer.

   >all I've done is a little exploratory work, and I'm offering the idea
   >to those who may have a little more.  It seems to me that this may
   >be a flier, and the objective of getting a functional, unencumbered C 
   >compiler on the Mac could be achieved at an early date.  I'd like to
   >generate a discussion on the merits of such a project.

   I would like to see a free C compiler on the Mac.  Any compiler.
   Simple support for minimal C features, no major optimizations needed.
   All it needs to be is reliable.

   Unfortunately, even starting with Sozobon, it's a BIG job.  It may be
   less work than gcc, in which case I'd support the idea.  The fastest
   route to a free, stable C compiler is a good road.  What we seem to
   need are people with free time, which we don't have.

   -- 
   Eric W. Sink, Spyglass        | "In all the earth, only humans have the ability
   1800 Woodfield Drive          |    to be content in bad situations...
   Savoy, IL  61826              |    and vice-versa."
   ---- e-sink@uiuc.edu ---------|---------- 217-355-6000 -----------------------


Brad Pickering
brad@tazboy.jpl.nasa.gov