Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!mips!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!rice!titan!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.arch Subject: Re: Prefetch instruction (was Re: BitBlt, new instructions for RISC.) Message-ID: <5384@brazos.Rice.edu> Date: 1 Mar 90 17:38:36 GMT References: <7466@pdn.paradyne.com< <7488@pdn.paradyne.com> <203@zds-ux.UUCP> Sender: root@rice.edu Distribution: usa Organization: Rice University, Houston Lines: 26 In article <203@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: in reply to alan@oz.paradyne.com (Alan Lovejoy) and Benjamin Chase >I can think of a simpler way to do this, with an instruction just like load >except it doesn't wait for the memory operation to complete or write a >register, its only effect would be to do a read to fill the cache line. Yes indeed. That's just what Ben suggested. I call it cache prefetching and he called it "whispering gently in the processor's ear", but it seems like a good idea either way. Of course, we want the cache miss handling to occur asynchronously with normal processing. That is, don't freeze the processor just because there's a reload happening. >Of course if my interpretation is correct, the 88k >can accomplish almost the same thing with its scoreboard; the compiler just >move the load itself up. The only difference is when the register gets >allocated. Right, assuming cache misses are handled like I want. Of course, we suddenly see a need for lots of registers. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu