🚀 go-pugleaf

In article <156@dg.dg.com>, mpogue@dg.dg.com (Mike Pogue) writes:
> In article <102441@sun.Eng.Sun.COM> jek3@sun.UUCP (Joseph Kowalski) writes:
> >R2000 at 8 Mhz (or other sadism), but I feel that the following is a much
> >more meaningful comparison than 'Mhz for Mhz':
> >
> >	Compare performance on the highest performing currently available
> >	implementation of an architecture in a given technology

In the real world the main thing to optimise is price/performance so we
should be looking at what MIPS/MFLOPS can be achieved within a given
development timescale, development budget and unit cost. Thats fine for
embedded controllers but for Unix boxes there is also the issue of applications
software. SPARC has over 500 applications, increasing at a very high rate.
What do the other vendors claim? Sun claims that SPARC has more 
applications software than all other RISC systems put together in a recent
SPARCware glossy.

>    Over time, MIPS, SPARC, and the 88K will all have pretty much the same 
> clock rates, and will use the same feature sizes.

Given the same development resources and the same types of implementation
that might be true. Right now there are more design teams working on more
different future SPARC implementations because it is licensed to TI, Fujitsu,
Cypress/Ross Technology, LSI, Prisma, Solbourne etc. The 88K only has
Motorola and MIPS do all the chip designs themselves. I think that the 
competition between SPARC vendors to have the best performance will 
encourage more innovative developments. Right now Cypress has 40 MHz SPARC
available, MIPS are at 25 MHz? 88K at 20 MHz?

>    When we decided to go RISC, we evaluated all three of these technologies,
> and finally decided that they were pretty similar architecturally.  The 88K
> had better multiprocessor hooks, but that was a relatively minor 
> consideration.

For a really nice multiprocessor implementation check out the Cypress CY7C605
Multiprocessor Cache/MMU (CMU-MP). It is designed by the people who left
the Motorola 88K design team to set up Ross Technology. Cypress gave a series
of seminars earlier this year and there is a good description in their RISC
seminar notebook.
 
>    Architecturally, you HAVE to compare Mhz for Mhz, or you are not looking at
> architecture.

It depends how you define architecture. For SPARC the architecture is basically
limited to the instruction set and registers. The user level instructions are
a fixed part of the SPARC ABI and implementation variations are handled by the
kernel. In fact the number of cycles taken to execute an instruction
is not part of the architecture and varies between SPARC implementations. For
example floating point instructions are despatched in two cycles on a Fujitsu
SPARC chip and in one cycle on a Cypress SPARC chip. All this makes MHz to MHz
comparisons an *implementation* comparison not an architecture comparison.

>    Mike Pogue
>    Data General Corp.

Adrian Cockcroft	std.disclaimer: these are my personal opinions.
Sun Cambridge UK TSE
sun!sunuk!acockcroft

(Borrowing Jerry West's account at Mountain View to get at USENET)