Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!cam-cl!cet1
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.arch
Subject: Decoding in I-cache (was Re: RISC definition)
Message-ID: <1872@gannet.cl.cam.ac.uk>
Date: 4 May 90 22:13:35 GMT
References: <26407B03.9044@paris.ics.uci.edu>
Sender: news@cl.cam.ac.uk
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 26

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.
>
Of course, if you can't guarantee the the instruction alignment (as you can 
on most RISCs and can't on most CISCs) then there is always the possibility 
that you might later read the same bytes back from the I-cache but grouped
into different instructions. It would be possible to do an OOPS---RESET THE
WORLD in this situation, admitedly.

There is a throw-away remark in the Grohoski-Kahle-Thatcher-Moore paper on  
the `Branch and Fixed-Point Instruction Execution Units' in the IBM collection
(SA23-2619) on the RS/6000 that `as instructions return from the memory 
system {to the I-cache} they are predecoded into eight general operating    
code classes'. Does anyone know any more about this? It doesn't seem like   
enough extra information to speed up subsequent decoding unless the division
into eight categories is an awfully complicated Boolean function of the     
instruction bits.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk