Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Smart I-cache? And separate R/W D-cache
Message-ID: <16004@cbmvax.commodore.com>
Date: 21 Nov 90 09:44:54 GMT
References: <2823@crdos1.crd.ge.COM>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 22

In article <2823@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  The feature is intelligent I-cache, which only stores instructions
>which are the target of jumps. The basis of this is that pipelines make
>cache less effective for long inline runs of code. In fact, in most
>cases there is nothing to be gained by caching these instructions,
>unless the memory bandwidth is really overloaded, such as by many DMA
>devices or multiple CPUs.

	This is known as a "Branch Target Cache" or BTC.  Both the RPM-40
and the AMD 29000 have BTCs (you can probably dig up some of the RPM-40
design team around CR&D - Try Dave Nagy, Janet Moseley, or Dave McGonagle
(who has a company at the RPI incubator center nowadays)).

	If you can feed instructions into the CPU from memory (or second-
level cache) at full speed, then all you need to cover is the branch
latency to restart the pipeline from memory, and a BTC covers this nicely.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
Thus spake the Master Ninjei: "If your application does not run correctly,
do not blame the operating system."  (From "The Zen of Programming")  ;-)