Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cca!mirror!ima!johnl
From: zrm@EDDIE.MIT.EDU (Zigurd R. Mednieks)
Newsgroups: comp.compilers
Subject: Re: Recommendable 68k C compilers
Message-ID: <686@ima.ISC.COM>
Date: Fri, 21-Aug-87 14:07:56 EDT
Article-I.D.: ima.686
Posted: Fri Aug 21 14:07:56 1987
Date-Received: Sun, 23-Aug-87 07:00:53 EDT
References: <683@ima.ISC.COM>
Sender: johnl@ima.ISC.COM
Reply-To: zrm@EDDIE.MIT.EDU (Zigurd R. Mednieks)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 26
Approved: compilers@ima.UUCP

In article <683@ima.ISC.COM> decvax!ucbvax!hplabs!felix!preston (Preston Bannister) writes:
>We use the Green Hills compiler here.  I don't see how Green Hills
>burns performance by using 32-bit ints.  Especially since they seem to
>benchmark faster than any other compiler!  :-)  In general it seems to

The Macintosh Programmer's Workbench compiler is the Green Hills
compiler and it bechmarks about 10% slower than the fairly simple
Aztec C and LightspeedC compilers. I've read tons of GreenHills
generated code and I know the potential is there, considering how good
the code is, but the fact remains that on 68000s, using 32 bit ints
does cost you at least 10% in performance. Let me emphasize that the
68000, not the 68020, is the target for which those benchmark figures
hold true. I would expect the Green Hills compiler to do much better
on the 68020.

By the way, there is no need to clear the high word of a register when
using the default 16-bit word length on 68000 instructions. I would
rather see a compiler's cleverness applied to taking good advantage of
16 bit ints than frittered away on compensating for 32 bit ints.

-Zigurd
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request