Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC definition
Message-ID: <38483@mips.mips.COM>
Date: 3 May 90 19:19:15 GMT
References: <2756@sunquest.UUCP> <151@exodus.Eng.Sun.COM> <1192@m1.cs.man.ac.uk> <1990Apr27.161912.15649@robohack.UUCP> <1252@m1.cs.man.ac.uk> <48577@ames.arc.nasa.gov> <26407B03.9044@paris.ics.uci.edu>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 49

In article <26407B03.9044@paris.ics.uci.edu> baxter@ics.uci.edu (Ira Baxter) writes:
>>The difference is simply that the "slow" machines all have operand specifiers
>>which need to be decoded.  Therefore, a meaningful definition of RISC vs
>>CISC is just that: simple operand specifiers vs decoded operand specifiers.
>>All you need to do is come up with some sort of phrasing of that fact so
>>that the acronyms are RISC and CISC :-)

>If this were all there were to it, why couldn't one decode an instruction
>on fetch from main memory, and simply store the decoding information
>along with the PC value into the I-cache rather than storing the instruction
>there?  A cache with a 50nS hit, 300nS miss, 95% hit rate would deliver
>roughly 16 million *decoded* instructions per second to the CPU.

This kind of thing has been done, of course, and is certainly one of the
good potential ways for CISCs to get faster.  Of course, it costs,
because now you've got another hunk of storage that wants to be fast
and bigger than a register set, as well as extra circuitry for saving the
decoded state, some really wide datapaths, potentially (consider the
expanded form of the longest VAX instructions...  obviously, this would
work better with X86 or 68K), appropriate mechanisms for invalidation
in addition to the cache invalidation.

Anyway, this is certainly a plausible method, especially when you get
lots more transitors on a chip. On the other hand, at the same level of
technology, the RISC gets to use the same space for other useful
things.

Finally, even with pre-decoded, OTHER CISC-typical things still are
impediments, like:
	condition codes with single-CC bottlenecks
	unaligned addressing and need to cope with multiple translations
		and exceptions in middle of pipeline, per data reference
	less registers

Also, let me agree with various posters, who think that getting a
really solid metric of RISC-vs-CISC is silly.  I give a talk that starts:

"How many of you in audience use RISCs?" (some, more than used to)
"How many use CISCs?" (lots)
"How many aren't sure what's in there?" (laughs)
"How many could care less, as long as it's, fast, cheap, and runs your s/w?"
	(all hands)
	(and of course, as baum points out, there are plenty of other
	relevant metrics)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015 or 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086