Article View: comp.arch
Article #3509Re: Dynamic internal state (was Re: Scoreboards / Load-interlocks)
From: Colin Plumb
Date: Mon, 19 Mar 1990 05:44
Date: Mon, 19 Mar 1990 05:44
14 lines
1156 bytes
1156 bytes
>> I saw an interesting idea >> in a paper about the SPUR cache - it proposed using dynamic RAM cells for an >> on-chip I-Cache (to save area), In article <39538@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: > If it's what I'm thinking of, its a cute idea. Guarantee that the 'valid' bit > decays before any of the others, and its easy. That is *sneaky*. Now, refresh the entry in case of a cache hit. If the entry hasn't been used in a few milliseconds, it will be purged. Not-recently-used! It may be impractical for other resaons, but it has serious hack value. -- -Colin
Technical Details
Message-ID:
<22182@watdragon.waterloo.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watdragon!lion!ccplumbReferences:
<11337@encore.Encore.COM> <3300106@m.cs.uiuc.edu> <32937@shemp.CS.UCLA.EDU> <132903@sun.Eng.Sun.COM> <39538@apple.Apple.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watdragon!lion!ccplumb From: ccplumb@lion.waterloo.edu (Colin Plumb) Newsgroups: comp.arch Subject: Re: Dynamic internal state (was Re: Scoreboards / Load-interlocks) Message-ID: <22182@watdragon.waterloo.edu> Date: 19 Mar 90 05:44:16 GMT References: <11337@encore.Encore.COM> <3300106@m.cs.uiuc.edu> <32937@shemp.CS.UCLA.EDU> <132903@sun.Eng.Sun.COM> <39538@apple.Apple.COM> Sender: daemon@watdragon.waterloo.edu Reply-To: ccplumb@lion.waterloo.edu (Colin Plumb) Organization: U. of Waterloo, Ontario Lines: 14