home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / programm / 20435 < prev    next >
Encoding:
Text File  |  1992-12-30  |  5.6 KB  |  121 lines

  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!elroy!brad
  3. From: brad@tazboy.jpl.nasa.gov (Brad Pickering)
  4. Subject: Re: Sozobon C - a free C for the Mac, too?
  5. In-Reply-To: e-sink@uiuc.edu's message of Tue, 29 Dec 1992 23:26:02 GMT
  6. Message-ID: <BRAD.92Dec30101828@tazboy.jpl.nasa.gov>
  7. Sender: news@elroy.jpl.nasa.gov (Usenet)
  8. Nntp-Posting-Host: tazboy.jpl.nasa.gov
  9. Organization: Jet Propulsion Laboratory, Pasadena, CA
  10. References: <29848@castle.ed.ac.uk> <C01nrF.5ps@news.cso.uiuc.edu>
  11. Distribution: comp
  12. Date: Wed, 30 Dec 1992 18:18:28 GMT
  13. Lines: 106
  14.  
  15. In article <C01nrF.5ps@news.cso.uiuc.edu> e-sink@uiuc.edu (Eric W. Sink) writes:
  16.  
  17.    Newsgroups: comp.sys.mac.programmer
  18.    Path: elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!ux2.cso.uiuc.edu!sink
  19.    From: e-sink@uiuc.edu (Eric W. Sink)
  20.    References: <29848@castle.ed.ac.uk>
  21.    Originator: sink@ux2.cso.uiuc.edu
  22.    Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  23.    Reply-To: e-sink@uiuc.edu
  24.    Organization: University of Illinois at Urbana
  25.    Distribution: comp
  26.    Date: Tue, 29 Dec 1992 23:26:02 GMT
  27.    Lines: 70
  28.  
  29.    Can't resist a few comments on this one:
  30.  
  31.    ngse18@castle.ed.ac.uk (J R Evans) writes:
  32.  
  33.    >Language implementations for the Mac, free of restrictions, are a little
  34.    >thin on the ground when compared with other platforms.  Although gcc has
  35.    >been ported to the Mac, it requires the proprietory MPW environment.  
  36.    >Eric Sink offered his 'Harvest C' to the community some months back,
  37.    >but himself describes it as an inappropriate line of development, and
  38.    >has encouraged hackers to concentrate their efforts through the TopSoft
  39.    >group on providing an unfettered environment for gcc, using the Harvest
  40.    >user interface as a starting point.
  41.  
  42.    Minor point: actually it is not the user interface which is viable
  43.    from Harvest C, it is the linker, and maybe the assembler.  You could
  44.    use the GUI too if you liked, but that's not the hard part to rewrite.
  45.  
  46.    [ Why not Sozobon C ? ]
  47.  
  48.    >Unlike Harvest C, which by its author's statements needs
  49.    >substantial further debugging, Sozobon C has gone through several stages
  50.    >of refinement and produces workmanlike code (e.g. it can compile itself
  51.    >reliably).
  52.  
  53.    >I suspect that a port to the Mac is not too horrendous a job, and I spent
  54.  
  55.    Perhaps bigger than you might think.  Early versions of Harvest C could
  56.    self-compile reliably too.  Those version were on par with Sozobon
  57.    in features: simple C compilation with no special support for Mac
  58.    compilation.  THEN, I added Mac A5 globals, support for pascal functions,
  59.    and so on.  THEN, you need a way to link.  What object files are you
  60.    going to generat e, and what will link them ?  Back to compilation,
  61.    what about traps ?
  62.  
  63. MacMINIX uses a standard K&R C compiler that doesn't know anything about
  64. using A5 as a globals pointer or about pascal functions.  This compiler
  65. can be used to generate Mac applications.  Traps are called through glue
  66. routines that convert the C calling conventions into Pascal calling
  67. conventions and setup register A5 from a global variable before actually
  68. calling the trap.  Global variables are not relative to A5, but absolute
  69. addresses that are relocated when the program starts.  Subroutines are
  70. not called through jump tables but through absolute addresses, also
  71. relocated at program startup.  Mac applications generated with this
  72. compiler have a special CODE 0 resource which contains 1 jump table
  73. entry which loads and calls the main program which relocates itself
  74. before referencing any global variables.  I have used these techniques
  75. to build mac applications on a sun using gcc.  I don't think that
  76. we are very far from a free development system for the mac.  It
  77. will certainly not be as convenient as Think C, but what can we expect
  78. for free.
  79.  
  80.    >So given that we can have a basic small compiler running quickly, just how 
  81.    >big a job might it be to make this produce Mac code?  Comments sought!
  82.    >[e.g. Sozobon doesn't know about the specialised purposes assigned within 
  83.    >the Mac to A5, but apart from telling the compiler to leave A5 alone, 
  84.    >I guess most of this stuff will appear in the libraries? Is that so? -- 
  85.    >As is probably obvious, I've done comparitively little Mac programming.]
  86.  
  87.    Lots of work.  Actually producing the assembler instructions for C code
  88.    is the "easy" part.  Turning all that into a Mac application is much
  89.    harder.
  90.  
  91.    >Just in case anyone runs away with the idea that *I* might produce
  92.    >such a compiler, let's say here and now that I don't have the time --
  93.  
  94.    bummer.
  95.  
  96.    >all I've done is a little exploratory work, and I'm offering the idea
  97.    >to those who may have a little more.  It seems to me that this may
  98.    >be a flier, and the objective of getting a functional, unencumbered C 
  99.    >compiler on the Mac could be achieved at an early date.  I'd like to
  100.    >generate a discussion on the merits of such a project.
  101.  
  102.    I would like to see a free C compiler on the Mac.  Any compiler.
  103.    Simple support for minimal C features, no major optimizations needed.
  104.    All it needs to be is reliable.
  105.  
  106.    Unfortunately, even starting with Sozobon, it's a BIG job.  It may be
  107.    less work than gcc, in which case I'd support the idea.  The fastest
  108.    route to a free, stable C compiler is a good road.  What we seem to
  109.    need are people with free time, which we don't have.
  110.  
  111.    -- 
  112.    Eric W. Sink, Spyglass        | "In all the earth, only humans have the ability
  113.    1800 Woodfield Drive          |    to be content in bad situations...
  114.    Savoy, IL  61826              |    and vice-versa."
  115.    ---- e-sink@uiuc.edu ---------|---------- 217-355-6000 -----------------------
  116.  
  117.  
  118. Brad Pickering
  119. brad@tazboy.jpl.nasa.gov
  120.  
  121.