Path: utzoo!news-server.csri.toronto.edu!rutgers!gatech!usenet.ins.cwru.edu!agate!krste
From: krste@ICSI.Berkeley.EDU ( Krste Asanovic)
Newsgroups: comp.arch
Subject: R4000 data cache stalls
Keywords: R4000
Message-ID: <1991Mar13.104148.25097@agate.berkeley.edu>
Date: 13 Mar 91 10:41:48 GMT
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: International Computer Science Institute, Berkeley, CA
Lines: 24
Originator: krste@icsib13

Looking back at an old posting about the R4000 I noticed the following:

In article 21694 of comp.arch John Mashey wrote:
    >
    >How do stores work?  I can think of lots of possibilities ...
    >Is the pipelining of word stores and partial word stores the same?
    They work straightforwardly: you can do back-to-back stores, loads,
    loads/stores without any stalls, assuming cache hits, of course,
    and regardless of byte/half/word/double type.

The uP Report article states that the on-chip data cache is
write-back, with a block size of 16 or 32 bytes. Would anyone at MIPS
care to enlighten me as to how they managed to avoid stalls in
back-to-back runs of cache accesses?

Write-back implies that the cache may have the only valid copy, and so
stores must wait to check tags before stomping on the data in cache.
Doesn't this mean that stores access the cache data RAM at a different
pipestage (WB?) than loads (DS?), and hence that a store followed a
couple cycles later by a load will cause a stall? I doubt the cache
RAM would be dual-ported.

Thanks,
Krste