home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!stanford.edu!apple!NewsWatcher!user
- From: tim@apple.com (Tim Olson)
- Newsgroups: comp.arch
- Subject: Re: How does an R4000-style cache work?
- Message-ID: <tim-080193085353@129.38.222.43>
- Date: 8 Jan 93 14:59:24 GMT
- References: <1993Jan6.235455.25425@Princeton.EDU> <1993Jan7.201733.16338@csrd.uiuc.edu>
- Sender: daemon@Apple.COM
- Followup-To: comp.arch
- Organization: Apple Computer Inc. / Somerset
- Lines: 28
-
- In article <1993Jan7.201733.16338@csrd.uiuc.edu>, grout@sp90.csrd.uiuc.edu
- (John R. Grout) wrote:
-
- > So, the indicated solution is:
- >
- > 4) Put the data in a write buffer until tag check.
- >
- > On a cache miss, stall the pipeline and write the data to cache as part
- > of miss processing.
- >
- > On a cache hit, put the data to the store buffer and unload it when:
- >
- > a) The cache bandwidth is available: no pipeline effects.
- > b) A load which wants to use the results of the store is
- > detected: stall the pipeline and empty the store buffer.
- > c) The store buffer is full: not clear (is this handled like case "b"?)
-
- Case c) probably never occurs -- a store can sit in the store buffer of the
- cache until another store occurs, at which time the first store can use the
- second store's pipeline slot to write into the cache (as long as tag
- addressing and cache data addressing are split). We used the same trick on
- the Am29000 to multiplex the single register-file writeback port between
- ALU results and LOAD results (as LOAD results come back sometime after the
- LOAD's writeback slot has passed...)
-
- -- Tim Olson
- Apple Computer Inc. / Somerset
- (tim@apple.com)
-