Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!netcom!craig
From: craig@netcom.COM (Craig Hansen)
Newsgroups: comp.arch
Subject: Re: SPARC implementation or architecture
Summary: Authors should have clarified instructions versus cycles
Message-ID: <1991Apr24.163947.1498@netcom.COM>
Date: 24 Apr 91 16:39:47 GMT
References: <1991Apr17.183822.7681@elroy.jpl.nasa.gov> <41377@cup.portal.com> <KHB.91Apr23193227@chiba.Eng.Sun.COM>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 39

In article <KHB.91Apr23193227@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:
> Marketing departments reserve the right to change stories as
> circumstances dictate ;>

IMHO, the Mips folk have been too gentle in their clarification
of the "results" of the paper. The single largest difference in
the results can be attributed to the fact that the Mips
implementation uses two instructions, that take two cycles,
to load or store a double-precision floating-point value, while
the Sun implementations use one instruction, that takes three or four
cycles to do the same operation. To express this as an advantage
for Sun is intellectually dishonest. The paper itself says:

	"If MIPS had double-precision loads and stores, it
	could reduce its instruction count by 19% in the SPEC
	FP benchmarks."

The basic premise of the
paper, to compare "architectures" rather than "implementations"
rests only on the following reason:

	"...because implementations change more frequently
	than instruction set architectures."

There is no further justification given, and it turns out that
this reasoning is false.

The 2.10 compiler release used to examine the MIPS code is
capable of generating the "MIPS-II" instruction set, which
includes load and store double. Mips has changed the
instruction set architecture just as frequently as the
implementation, with the exception of the R2000-to-R3000 change,
which was a pin-compatible modification that did not change
the width of the data interfaces.

Let me close by admitting by own obvious biases: I am a former
Mips employee who had a hand in the development of both
architecture and implementation there. I am typing this
message on a SPARCstation 2.