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) |
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.
-Zigurd
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.