Re: Recommendable 68k C compilers

zrm@EDDIE.MIT.EDU (Zigurd R. Mednieks)
21 Aug 87 18:07:56 GMT

          From comp.compilers

Related articles
Recommendable 68k C compilers harvard!rutgers!EDDIE.MIT.EDU!zrm (1987-08-19)
Re: Recommendable 68k C compilers decvax!ucbvax!hplabs!felix!preston (1987-08-20)
Re: Recommendable 68k C compilers zrm@EDDIE.MIT.EDU (1987-08-21)
Re: Recommendable 68k C compilers harvard!seismo!geac!daveb (1987-08-22)
| List of all articles for this month |

From: zrm@EDDIE.MIT.EDU (Zigurd R. Mednieks)
Newsgroups: comp.compilers
Date: 21 Aug 87 18:07:56 GMT
References: <683@ima.ISC.COM>
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA

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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.