Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!dg!Publius
From: Publius@dg.dg.com (Publius)
Newsgroups: comp.arch
Subject: Re: RISC definition
Message-ID: <430@dg.dg.com>
Date: 4 May 90 14:55:02 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>
Reply-To: publius@dg-pag.webo.dg.com (Publius)
Organization: Data General, Westboro, MA.
Lines: 19

In article <26407B03.9044@paris.ics.uci.edu> baxter@ics.uci.edu (Ira Baxter) writes:
>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.


The time is not spent in instruction decoding per se.  Rather, it is due to
the fact that a CISC instruction has to be broken down into a few
"micro-operations" to be handled by hardware.  By breaking down the
CISC instruction barrier among micro-operations, RISC allows better
pipelining and micro-parallelism and thus achieves better performance.

-- 
Disclaimer: I speak (and write) only for myself, not my employer.

Publius     "Old federalists never die, they simply change their names."
publius@dg-pag.webo.dg.com