Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!claris!wombat
From: wombat@claris.com (Scott Lindsey)
Newsgroups: comp.sys.apple
Subject: Re: gcc for the gs
Message-ID: <9171@claris.com>
Date: 24 Mar 89 00:21:50 GMT
References: <11464@louie.udel.EDU>
Organization: Claris Corporation, Mountain View CA
Lines: 58

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.