🚀 go-pugleaf

In article <1014@ames.UUCP> fouts@orville.UUCP (Marty Fouts) writes:
>However (Flame on, Thrusters to FULL :-(  The only response I've
>gotten, (both here from Paul Rubin, and elsewhere from Len Tower) from
>people who appear to be associated with FSF has been abuse.  I would
>suggest that if FSF wants support from a user community, they would be
>better served by supporting that user community than by p*ss*ng on it.
>
>Marty


I regret Marty's having felt abused by my article.  I was trying to be
friendly and helpful, pointing out some difficulties he might
encounter in doing his port, and expressing my bewilderment at his
suggestion that "the best use of GCC is as a code generator for
another compiler".  I haven't seen what Len Tower sent Marty, but I
know Len and doubt very much if he said anything that he intended to
be the least bit abusive.

To most compiler hackers, "code generator" means the part of a
compiler that emits machine code (or assembly code) from whatever
internal representation the compiler has made for your program.  Other
parts of a compiler include the lexical analyzer, the parser, etc.
Assemblers and loaders are generally considered distinct programs from
compilers.  It sounded like Marty was proposing to use a different
compiler's front end with a GCC back end, which for various reasons
isn't such a good suggestion (e.g. it probably requires you to have
source code for the other compiler).  It turns out that Marty was using
the term "code generator" to mean what is usually called a "compiler",
and apparently "compiler" to mean "compiler, assembler, linker, and
runtime library".  His ";-)" suggests he expected me to have
understood this; however, I didn't.  (N.B. I am not trying to get into
an argument over terminology.  It's just that people must agree on
definitions in order to understand one another, and in this case, we
didn't).

Back to the subject of porting GCC to an ST: I would be happy to see
this done and will say a little more about what is needed: basically,
an assembler and linker and a runtime library.  Marty has suggested
(if I now understand his suggestion) using these parts from an
existing ST C compiler system.  This might be a good way for ST
users interested in playing with GCC to get started quickly, but it
has a few problems:
  1) those systems might not include an assembler, or at least not
     not one with the same assembly format that GCC produces (although
     GCC could be changed)
  2) Similarly, the calling conventions of the runtime library might
     not be compatible, and
  3) most important, all the existing ST compiler systems that I know
     of are proprietary.  However, I believe there are some free
     assemblers and linkers around.

If there are no suitable free assemblers available, it might be
possible to adapt the GNU assembler (which is not yet finished).  The
GNU linker probably won't be of any use for this because the Gemdos
load format is so different from GNU's.

You'll also need to have a runtime library to interface with Gemdos
primitives and/or talk to the ST hardware.  An Atari-using friend of
mine who has been interested in porting the compiler says that this
shouldn't be too hard to write.  There are also some machine
independent parts for which there is free code available that you
could start from.  Contact me by mail if you want help with this.

Please stop feeling abused, and don't feel discouraged from trying to
port GCC, and do distribute your results when you have some.