Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!sics.se!sics.se!tege
From: tege@sics.se (Torbj|rn Granlund)
Newsgroups: comp.sys.pyramid
Subject: Re: upgrading to OSx 5.od and gnu
Message-ID: <1990Oct4.120139.12531@sics.se>
Date: 4 Oct 90 12:01:39 GMT
References: <1990Sep28.205311.10896@swbatl.sbc.com>
	<129037@pyramid.pyramid.com>
Sender: news@sics.se
Organization: Swedish Institute of Computer Science, Kista
Lines: 28
In-Reply-To: csg@pyramid.pyramid.com's message of 2 Oct 90 16:20:27 GMT


   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.

I have quite a different experience.  GCC produces *much* better code
that pyramid's native compiler.  All examples I have tried are at
least as fast, and sometimes twice as fast when compiled with GCC.
Also, code sics is smaller.

It is possible to construct programs that run faster when compiled
with pyramid's compiler.  Since the registers have virtual 32 bit
addresses, pyramid's compiler doesn't allocate registers whose addres
is taken to memory, while GCC does allocate then to memory.  But who
writes optimized code relying on hevy usage of such registers?

I have had problems with pyramid's compiler, and there are still some
workarounds in the GCC pyramid specific sources, to simplify
bootstrapping.  If anyone knows any bugs in the GNU C pyramid port,
I'd be more than happy to fix them!
--
Torbjorn Granlund