wack@udel.EDU (Andrew Wack) (03/24/89)
In article <9167@claris.com> wombat@claris.com (Scott Lindsey) writes: >From article <2692@ncsuvx.ncsu.edu>, by mikes@ncsuvx.ncsu.edu (Michael Steele): >> >> Will someone PLEASE port gcc to the GS. I would do it but my >> knowledge of 65816 assembly isn't too hot. GCC is a PD compiler >> available for UNIX machines, Amigas, and Atari ST's ( the group >> of PC's that the Gs should be in). > >If someone can get me gcc source I'll be glad to start working on a port >part-time... I can't ftp from this machine. I really don't know how big a >project it'll be. The compiler will have to compile down to object code... >not to assembly: doing it like pcc & just using the system assembler would >be slow as all get-out. But this means that the compiler has to know about >OMF... I've been watching the discussion about gcc here and I thought I would give a few reasons why it would be VERY difficult (notice I did not say impossible) to port it to the GS. I have the manual (150 pages, typeset) that describes how to port it and after reading it about 4 times here is what I have found: 1. gcc uses machine description files for each machine it is to be used on. This file describes the entire target machine's instruction set in terms of rtl (register transfer language). I have heard that it takes about 4 months of hard work to become profficient enought to write this machine description, and after starting to attempt the task, I believe it. (This method of porting does make it much easier in general, however, since the rest of the compiler doesn't change) 2. gcc is designed to generate assembly code to be passed to the assembler. Altering it to generate object code would be a major task. Just for reference the source code is about 6 Meg with only about 30% of that being comments. 3. gcc is really designed for 32 bit machines, with several registers. This isn't hard coded (it is one of the parameters included in the machine description) so this probably wouldn't pose too many difficulties. 4. The final problem that I see (at least for the moment) is that when compiled gcc is HUGE!! Typically it is between 1 and 2 Megabytes of object!! Break out those big memory cards and large hard drives!! To gcc's credit, one of the reasons it is so large is that gcc can perform about every code optimization in the book...thus it tends to generate very good code. These are just my observations from playing with gcc for a few months.. any and all comments about this project are welcome. As I said, I feel this project is very difficult, not impossible. I just wanted to post my observations so that we don't see a fload of people wondering were that new great gcc compiler for the gs went to..... ------------------------------------------------------------------------------- Andrew Wack wack@udel.edu
wombat@claris.com (Scott Lindsey) (03/24/89)
From article <11464@louie.udel.EDU>, by wack@udel.EDU (Andrew Wack): > 1. gcc uses machine description files for each machine it is to be > used on. This file describes the entire target machine's > instruction set in terms of rtl (register transfer language). > I have heard that it takes about 4 months of hard work to > become profficient enought to write this machine description, > and after starting to attempt the task, I believe it. (This > method of porting does make it much easier in general, however, > since the rest of the compiler doesn't change) Well, I'm a hacker first, a computer scientist second and a programmer third. I think I know where I can get hold of a GNU distribution tape... if so, I'll look into it. I may treat it as a challenge. Then again, I may not. > 2. gcc is designed to generate assembly code to be passed to the > assembler. Altering it to generate object code would be a > major task. Just for reference the source code is about 6 Meg > with only about 30% of that being comments. Well, I have resources to deal with that, initially. I would probably start it out either with the MPW C compiler (not MPW IIgs) or the one under SunOS4 (unix) with the intent of first producing a cross-compiler, and eventually a native compiler (if it looks feasible). As for dealing with OMF instead of just assembly, well, that's something I pointed out. I'm reasonably familiar with OMF now, but this may be the biggest stumbling block. > 4. The final problem that I see (at least for the moment) is that > when compiled gcc is HUGE!! Typically it is between 1 and 2 > Megabytes of object!! Break out those big memory cards and > large hard drives!! To gcc's credit, one of the reasons it > is so large is that gcc can perform about every code optimization > in the book...thus it tends to generate very good code. I would hope that by (eventually) compiling gcc with itself (and eliminating dead code) it could be cut down quite a bit to something reasonable for an end compiler. But no way am I going to try to interface with APW's screwy compiler/assembler/editor parameter passing interface. IF there ever is a native GS gcc from me, it'll be a stand-alone utility that takes it's parameters directly from the command line, like any good shell application. > These are just my observations from playing with gcc for a few months.. > any and all comments about this project are welcome. As I said, I feel > this project is very difficult, not impossible. I just wanted to post > my observations so that we don't see a fload of people wondering were > that new great gcc compiler for the gs went to..... I second this. I'm just interested in exploring the possibilities. Heck, what was that compiler class back in college for? -- Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or dead.
demarco@cpsc.ucalgary.ca (Vince Demarco) (03/24/89)
Well, how about we forget about gcc then and concentrate on something else-> How about turning Small C (available from one of the UNIX sources archives, can't remember the name of it at the moment) into a "semi-large" C?? This would include a preprocessor, the compiler which generates assembly code which can be assembled either as interpreted code or native 6502/816 code via macros... ideally, it should be able to use any macro assembler, but if not we could settle for Orca/MPW... What do you think of this idea?? if it works we my have a reasonable C compiler for the Apple-> hopefully it will also work on plain old //e,c's as well...