Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.arch Subject: Re: BitBlt, new instructions for RISC. Message-ID: <9844@cbmvax.commodore.com> Date: 27 Feb 90 01:01:45 GMT References: <7466@pdn.paradyne.com> Reply-To: jesup@cbmvax.cbm.commodore.com (Randell Jesup) Distribution: usa Organization: Commodore, West Chester, PA Lines: 25 In article Benjamin Chase writes: >Perhaps in the floating point slot of the superscalar instruction, >you'd put (among other things?) little hints to the cache instead? >Whisper gently into the processor's ear, saying "get the value in >register N, and use that as a stride for yanking words into the cache >until I tell you something different". This idea exists (though not in superscalar form) in the RPM-40 cache and coprocessor design. The cache control appears to the processor as a logical coprocessor. You can fill pipeline interlocks, load delays, etc with cache setup/hint instructions. The RPM-40 had lines going to the cache to tell it which register (if any) a load/store was relative to, which could be used by the cache to act differently according to register number. For example, access relative to register 1 might be sequential, relative to register 2 might skip X words on each access, register 3 might have random access habits, etc. (there were a couple of other things about it you could control also). For I-Cache, you could control how many entries of the Branch-Target-Cache (BTC) were handled by LRU, and how many the software wanted to provide the addresses to cache. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"