Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!sm.unisys.com!csun!polyslo!mdeale
From: mdeale@polyslo.CalPoly.EDU (Hmmm)
Newsgroups: comp.arch
Subject: Re: [HS]W interlocks
Message-ID: <8483@polyslo.CalPoly.EDU>
Date: 23 Feb 89 22:35:09 GMT
References: <28200269@mcdurb> <28200273@mcdurb> <3007@ardent.UUCP> <14619@cup.portal.com> <24435@amdcad.AMD.COM> <11058@tekecs.GWD.TEK.COM>
Reply-To: mdeale@polyslo.CalPoly.EDU (Hmmm)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 29

In article <11058@tekecs.GWD.TEK.COM> andrew@frip.wv.tek.com (Andrew Klossner) writes:
>>[]
>>	"If an on-chip I-cache can be built that will supply an
>>	instruction in a single-cycle (which it *has* to, in order to
>>	run at 1 inst/cycle), why can't a D-cache with the same
>>	characteristics exist?"
>
>The I-cache has a strong hint as to which instruction will next be
>fetched, and can have it ready.  The D-cache has no such hint.

   Take the Am29K for example. In Burst mode we do know what the
next instruction address will be. Pipeline mode too. However, the
D bus also has these two modes.

>And, on many machines, even the I-cache will take an extra cycle to
>supply an instruction if you surprise it by taking an unexpected branch
>(or by not taking an expected branch).

   This is one way to leave Burst mode. But why can't I use some of
those fast 10-12ns SRAMs from Performance Semi. or Micron Tech.?
[assuming cache control can respond quick enough]

>  -=- Andrew Klossner   (uunet!tektronix!orca!frip!andrew)      [UUCP]
>                        (andrew%frip.wv.tek.com@relay.cs.net)   [ARPA]


Myron
#mdeale@polyslo.calpoly.edu
#don't collect, connect.