🚀 go-pugleaf

In article <1048@orbit.UUCP> steve@pnet51.cts.com (Steve Yelvington) writes:
> GCC is the GNU C Compiler from the Free Software Foundation. I have not used
> it, but by reputation it is an excellent compiler whose primary sin is the
> requirement of a lot of RAM -- you probably need a Mega 2 or better to be
> happy with it.

I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I
found that its 68000 code generation is TERRIBLE.  It is beaten by ALL
the other Atari C compilers I could find (Dhrystone 2.1), by a factor of
two or more in some cases.  This includes using -O, but no other
optimization options; some may pay, others aren't available (like
"no-function-cse").  For 68020 the code quality is not substantially
better: it doesn't beat MWC's 68000 code (both running on a 68020 (well,
030), obviously).  And without the 68030's cache enabled, GCC's 020 is
worse than all but Aztec's +P (large code, data, and ints) 68000 code. 

My point is that this port of GCC stinks.  It could be that 1.3x is
better; I hope so.  I suspect that the GCC back-end was originally coded
for 68020, and somebody went in and made 68000 work from that; this
resulted in the bad times for 68000. 

These are the ST timings I got for Dhrystone 2.1.  (I can't publish any
non-ST times.) All are on the same ST, with the same things going on in
background (mainly checking for special "hot" keys; the background stuff
is why the times are slower than yours). 

COMPILER OPTIONS	NOREG	 REG
-------- -------	-----	----
GCC			 452	 475
GCC	-O		 540	 540
AZTEC	large		 768	 834
MWC			 986	1065
MWC	-O -Vpeep	1014	1091
ALCYON			 982	1097
AZTEC	small		1063	1161
TURBO	-GJMPRZ		1650	1730 (from J.Oklamcakn)

Aztec is version 3.6c; "large" is +P, meaning large code, large data,
and 32-bit ints; "small" means the defaults: small code (PC-relative)
small data (address-register relative) and 16-bit ints.  Aztec large and
GCC have 32-bit ints, all others 16.  Turbo C blows everybody else away
partly because they pass arguments in registers, and probably Julius ran
it on a bare ST (nothing running in Vblank). 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt