upgrading to OSx 5.od and gnu

Chris Anderson chris at utgard.uucp
Thu Oct 4 07:24:50 AEST 1990


In article <129037 at pyramid.pyramid.com> csg at pyramid.pyramid.com (Carl S. Gutekunst) writes:
>OK, maybe I'm just begging to be flamed, but I gotta ask: I can see writing a
>Pyramid CPU backend for gcc as a fun and useful pedagogical exercise. But why
>would anyone want to use gcc for production work instead of the Pyramid's
>native compiler? gcc doesn't generate anywhere near as good code (either local
>or global), and it has lots more bugs. If you want to write and compile strict
>ANSI C code, then I could see it; but ANSI C is the exception these days, and
>it's usually easy to convert to compile with K&R compilers. 

1.  For the error and warning messages.  Lots easier to scan through 
	than lint's, and once you've gotten most of them to vanish, your
	lint checks are much smaller as well.

2.  ANSI C  even though gcc isn't quite up to the ANSI standard, it's
	close enough to be quite usable.  And when you have a bunch of PC
	programmers who learned ANSI C instead of K&R, then it's easier to
	use gcc than teaching them K&R.

3.  You need it for g++.  Not that I have g++ running on a Pyramid, mind
	you, but when I do... (a side note, has anybody gotten good code out
	of g++ on a Pyramid?  I'd like to talk to you if you have.)

4.  Cross compiling environments.  

Other than that, no.  Pyramid's cc is faster, produces better
code, and has less bugs.  Much like you said.  You takes the 
good with the bad.

Chris
-- 
| Chris Anderson                                                       |
| QMA, Inc.                     email : {csusac,sactoh0}!utgard!chris  |
|----------------------------------------------------------------------|
| My employer never listens to me, so why should he care what I say?   |



More information about the Comp.sys.pyramid mailing list