🚀 go-pugleaf

In article <15226@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <210@intelca.intel.com> clif@intelca.intel.com (Ken Shoemaker) writes:
>...
>>The i860 CPU benchmark report had a TYPO the Dhrystone benchmark used
>>the Greenhill C compiler not FORTRAN.
>>Sorry to dissappoint everyone who thought that we were getting great
>>Dhrystone numbers by rewritting the benchmark in FORTRAN.
...
>>My speculation (note the word speculation) as to why the the Dhrystone 
>>numbers are so good is: 
>>
>>	Clock Frequency
>>	128-bit loads for string instructions
>>	The clocks/instruction is 1 (I imagine other RISC chips
>>	approach 1 clock/instruction but don't actually obtain it)
...
>2) OK, I give up.  There must be something unbelievably clever going on
>to use 128-bit loads for C-language string operations. I've looked
...
>doesn't have unaligned word operations.  For a fair test, you MUST
>use str* that only assume byte alignment of operands, and
>you can't inline the str*.  The only place I can think of using 128-bit
>loads is in the structure-copy, and it shouldn't be used there,
>unless structures whose largest entities are words are always aligned
>to 4-word boundaries, which seems unlikely.

	Actually, I think the statement "Greenhills C" was the giveaway.
We use Greenhills C here at Commodore for Amiga OS work, and got bitten recently
because the compiler was set up with the "dhrystone" optimizer turned on,
without our knowing it.  This causes mis-aligned strcpy()s to bus-fault on
68000, since it (a) assumes string sources AND destinations are ALWAYS word-
aligned, and (b) inlines strcpy, even though in general greenhills doesn't
do inlining.

	So I suspect the differences are being caused by the "dhrystone" switch
in Greenhills.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup