Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!uci-ics!baxter
From: baxter@ics.uci.edu (Ira Baxter)
Newsgroups: comp.arch
Subject: Re: RISC definition
Message-ID: <26407B03.9044@paris.ics.uci.edu>
Date: 3 May 90 18:40:03 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>
Lines: 29

lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

>In article <1252@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes:
[ discussion about RISC metric deleted]

>The problem with this debate is that the premise is incorrect.  The unstated
>premise is that RISC vs CISC is an important performance metric worth
>measuring.  But, what definition of "RISC" gives the distinction a
>difference?  Is there an architectural definition of RISC?

>Better to ask: Why have so many implementations of VAX, 68k, etc, been "slow"
>(such that comparable silicon implementations of competing architectures,
>such as MIPS, have been faster)?

>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.

Just a random thought.
--
Ira Baxter