Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!bacchus!mit-hermes!phr From: phr@mit-hermes.UUCP Newsgroups: comp.sys.atari.st Subject: Re: Porting GCC to Atari ST Message-ID: <2824@mit-hermes.AI.MIT.EDU> Date: Sun, 29-Mar-87 22:31:05 EST Article-I.D.: mit-herm.2824 Posted: Sun Mar 29 22:31:05 1987 Date-Received: Tue, 31-Mar-87 04:44:25 EST References: <3450@elroy.Jpl.Nasa.Gov> <975@ames.UUCP> <2822@mit-hermes.AI.MIT.EDU> <1014@ames.UUCP> Reply-To: phr@hermes.UUCP (Paul Rubin) Organization: The MIT AI Lab, Cambridge, MA Lines: 65 Keywords: C GCC Gnu FSF 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.