Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!ames!eos!shelby!neon!Gang-of-Four!andy
From: andy@Gang-of-Four.Stanford.EDU (Andy Freeman)
Newsgroups: comp.arch
Subject: Re: Decoding in I-cache (was Re: RISC definition)
Message-ID: <1990May7.230814.29306@Neon.Stanford.EDU>
Date: 7 May 90 23:08:14 GMT
References: <26407B03.9044@paris.ics.uci.edu> <1872@gannet.cl.cam.ac.uk>
Sender: news@Neon.Stanford.EDU (USENET News System)
Organization: Computer Science Department, Stanford University
Lines: 22

In article <1872@gannet.cl.cam.ac.uk> cet1@cl.cam.ac.uk (C.E. Thompson) writes:
>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.

There are two reasons to "decode".  The first is to put things into a
more useful form.  The second is to put things into a more useful
place, or maybe even several more useful places.  (VLIW/LIW machines
can have a separate I cache for each functional unit cluster, so that
the only thing they have to ship around is the PC.  One can save a bit
of hardware by using a single tag/match unit for all of the caches.)

-andy
--
UUCP:    {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy
ARPA:    andy@neon.stanford.edu
BELLNET: (415) 723-3088