home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / programm / 20728 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  3.9 KB
  1. Xref: sparky comp.sys.mac.programmer:20728 comp.sys.atari.st.tech:6495
  2. Newsgroups: comp.sys.mac.programmer,comp.sys.atari.st.tech
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!hanauma.jpl.nasa.gov!hyc
  4. From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
  5. Subject: Re: Sozobon (or other free C's): would this strategy work?
  6. Message-ID: <1993Jan5.223044.15575@elroy.jpl.nasa.gov>
  7. Sender: news@elroy.jpl.nasa.gov (Usenet)
  8. Nntp-Posting-Host: hanauma.jpl.nasa.gov
  9. Organization: SAR Systems Development & Processing, JPL
  10. References: <29879@castle.ed.ac.uk> <1993Jan5.023237.18823@cs.yale.edu>
  11. Distribution: comp
  12. Date: Tue, 5 Jan 1993 22:30:44 GMT
  13. Lines: 61
  14.  
  15. In article <1993Jan5.023237.18823@cs.yale.edu> bobf@flint.geology.yale.edu (Bob Fischer) writes:
  16. >J R Evans (ngse18@castle.ed.ac.uk) wrote:
  17. >: I week or so back, I offered the suggestion that it might be a
  18. >: reasonably modest task to convert Sozobon C (a fairly small K&R C for
  19. >: the Atari) to work on the Mac.  There has been some follow-up
  20. >: discussion....
  21. >
  22. >The outlined strategy may work, but I'm not so sure it's a good idea.
  23. >If I were going to port a C to the Mac, I'd do GNU C, and port it "the
  24. >right way".  Sure it's huge, but as you said, memory on the Mac isn't
  25. >such a big deal anymore.  The smallest Mac you can buy nowadays is 2
  26. >Mbytes, more than adequate for GCC.  My reasons for this assessment
  27. >follow:
  28.  
  29. >* GCC runs on many systems, including a zillion flavors of UNIX,
  30. >MS-DOS, and the Atari ST.  Therefore, a program written in GCC is more
  31. >likely to work on other systems than a program developed with _any_
  32. >other C compiler (like, say, SUN's compiler, or Mark Williams C).  A program
  33. >written with one GCC need only be compiled by another GCC to provide an
  34. >easy port.  Potential problems of hidden compiler incompatibilities
  35. >between systems are eliminated.
  36.  
  37. Not necessarily, some brain-dead CPU architectures still require weird
  38. machine-specific #pragma's to control their behavior. (Look at the i386
  39. support for GCC, for a notable example...)
  40. >
  41. >* GCC is backed by the Free Software Foundation.  This is not a
  42. >program which will lose support when one or two people taking care of
  43. >it decide to do something else.  (I know.  I wrote The Vault, and now
  44.  
  45. As others have already mentioned, the FSF is vehemently opposed to having
  46. GNU software ported to Apple platforms.
  47.  
  48. >* Finally, the most compelling reason is that I think that GCC would
  49. >be the easiest to port!  GCC was written in a modular way, so that it
  50. >can be ported to any system, running any instruction set.  What
  51. >porting it consists of is describing, in GCC's machine-description
  52. >language, the properties of your computer's instruction set.  The code
  53. >generators and optimizers use this information to generate code for
  54. >your computer.  Adding a new machine description to GCC does does not
  55. >eliminate the possibilities for GCC to generate code for other
  56. >machines.  (This means that GCC can be easily used as a cross-compiler
  57. >--- build the standard distribution to run on one system, but to
  58. >produce code for another.)  Since someone has already described the
  59. >68000 instruction set to GCC, you would just have to modify the
  60. >description, to make it work with the Mac quirks (like the special
  61. >status of A5).  To encourage people to port GCC, Richard Stallman
  62. >(author of GCC) has written a 190-page manual describing in detail how
  63. >to port GCC.  I don't believe any other program comes with such
  64. >carefully written porting instructions.
  65.  
  66. It probably would be pretty simple to customize the m68k description to
  67. support the Mac. Especially given that the Atari ST port now also uses
  68. a global data pointer (I chose a4 instead of a5; TOS clobbers a5 during
  69. a Supexec call). However, I don't see any reason to undertake this port.
  70. What's the ultimate purpose of this effort, just to have a freeware C
  71. compiler on the Mac?
  72. -- 
  73.   -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
  74.  
  75. There's a rough border between genius and insanity, but I'm a dual citizen.
  76.