Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!cernvax!ethz!forty2!poole
From: poole@forty2.UUCP (Simon Poole)
Newsgroups: comp.sys.atari.st
Subject: Re: Comment on PD/Shareware C compiler
Message-ID: <703@forty2.UUCP>
Date: 4 May 89 17:37:36 GMT
References: <1048@orbit.UUCP> <1471@atari.UUCP>
Reply-To: poole@forty2.UUCP (Simon Poole)
Organization: Exp. Physics University Zuerich
Lines: 69

In article <1471@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
........
>I got GCC version 1.23 for the ST from Simon Poole (indirectly), and I
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
May I point out that this is NOT TRUE! While a do have a copy of this
version of gcc: 
	a) I did not port it.
	b) I did not redistribute it (particulary not to the US)
(If this was an attempt at a flame Allan, it was rather badly aimed).

>found that its 68000 code generation is TERRIBLE......
This is actually true, the code produced with -m68000 and -mshort is
not very good, which is no wonder, since gcc is targeted for a 68020
and the -m68000 flags just tells it to avoid 68020 specific stuff.


                                               .....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").  .....

?as far as I remember, all the flags that are sensible work (and do give
some performance improvement).

		..... 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. 

I'm not quite sure what you are trying to prove with this statement,
that code that uses the mc68000 `small` model is faster than corresponding
`large` model code is no secret and not supprising. If you want to limit 
all your programs to 32kB data structures and 16 bit ints, please don't
let us stop you. (BTW did you try real programs or did you just try 
Drhystone????)

>
>My point is that this port of GCC stinks. ....
                       ^^^^
The machine description is the standard 68020 one, the code that is produced
has got nothing to do with the actual Atari port. As to the quality of the
68020 code produced (I've used/am using gcc on other machines) I can assure
you that gcc is pretty good, and that I'm not the only person that thinks so.

>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). 
[numbers deleted]

Using ONE number to classify a compiler is not a very good idea, I could
just as well claim that mwc and Turbo C  are broken because they fail on 
one moderately complex and long macro (in Flex). Gcc is interesting on
the ST, because:
	- it's an ANSI C compiler
	- it produces true `large` model code
        - the code produced for the above model is good
	- it has automatic register allocation
        - program size and complexity is only limited by available
          memory
	- it's free


-- 
----------------------------------------------------------------------------
							Simon Poole
Due to a new job these addresses will be going away after the 1. of June!
UUCP:   ...mcvax!cernvax!forty2!poole     BITNET: K538915@CZHRZU1A