🚀 go-pugleaf

>>>Results for the Sun-3/60 are not reported because the data in
>>>[Presentation on Benchmarks given at Sun User Group Conference, Dec 5-7,
>>>1988 by Sun Microsystems, Inc.] uses compiler optimization level 4 which
>>>employs procedure inlining.
>>
>>FYI, this is incorrect.  Current Sun C compilers do not perform procedure
>>inlining at any optimization level.
>
>Maybe you should look again

No, there's not much point in looking again; David is talking about
*general* procedure inlining, which the current Sun compilers do not do,
at least not to the best of my knowledge - a second look will almost
certainly confirm that.  This is quite different from the very
specialized inlining that the "inline" program performs (as I remember,
it performs inlining on the assembly-language output from the compiler),
so if the claim is that the 3/60 results used general procedure
inlining, the claim seems suspicious to me.  The only ".il" files I
could find on any of the 4.0 machines around here (both 68K and SPARC)
are 1) files for "libm" - in several flavors for the 68K machines - and
2) some for doing loads from possibly-misaligned locations. 

As far as I know, Dhrystone (the benchmark to which the comment about
the 3/60 refers) doesn't make heavy use of floating point (it's supposed
to be a synthetic systems programming benchmark, and systems programming
tends not to make heavy use of floating point) or the math library (if
it makes any use of it at all); furthermore, the 3/60 doesn't make use
of SPARC templates for handling misaligned data (it can handle it on its
own).  As such, "inline" is completely irrelevant to the discussion.