Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!sun!lowpost!jek3
From: jek3@lowpost.Sun.COM (Joseph Kowalski)
Newsgroups: comp.arch
Subject: Re: Criteria for comparing RISC processors
Message-ID: <102441@sun.Eng.Sun.COM>
Date: 2 May 89 19:47:44 GMT
References: <2368@ogccse.ogc.edu> <1464@cfa.cfa.harvard.EDU> <141@dg.dg.com> <18120@winchester.mips.COM> <144@dg.dg.com> <18316@winchester.mips.COM> <147@dg.dg.com> <18653@winchester.mips.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: jek3@sun.UUCP (Joseph Kowalski)
Organization: Sun Microsystems, Mountain View
Lines: 25

In article <18653@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <147@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:
>.....
>>                                       Note that compilers for the 88K
>>produce code RIGHT NOW with performance (Mhz for Mhz) equal to the MIPS 
>-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>compiler, which has been in development for years. 

I fail to see the preoccupation with 'Mhz for Mhz'. I certainly would like
to believe that one can design a simple state machine (like a D flip-flop)
to run at a higher clockrate than a DSP or CPU chip (like 88K or R3000).
If an architect chooses to implement an instruction set to aid compiler
designers/performance at the expense of clockrate, that's his design
decision. I certainly don't want to see 33 Mhz 88K compared against an
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

I realize that 'Mhz for Mhz' has more meaning in the RISC, ONE INSTRUCTION PER
CLOCK world than in the CISC world, but even this is doubtful.

Joe Kowalski (No fancy signature - My opinions are obviously my own - I tried,
	      but I couldn't give them away!)