Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: Caches
Message-ID: <918@m3.mfci.UUCP>
Date: 28 Jun 89 14:24:28 GMT
References: <799@acorn.co.uk> <95@altos86.Altos.COM> <195@dg.dg.com>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 38

In article <195@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes:

>7	write with invalidate [write to non-resident line] 
>
>At this point, a write through cache seems simpler.  However, if the
>line size is greater than a single word, the number of states increases
>substantially.  Specifically, the case in (7) becomes:
>
>	cache line read,
>	word write to cache, (may take place simultaneously with below)
>	word write to memory
>

I.E. A read-modify-write to cache, along with the memory write.

Not all write-thru caches will require a RMW even if the line size is larger 
than the word size. Some will store a seperate copy of the tag (or cache 
index) with each word. 

If you want a byte-writable cache, you probably _will_ do RMWs. :-)

-------

Another point that I haven't seen yet:

Write-back caches are vulnerable to SRAM soft errors. Many write-thru
systems will force a miss if a parity error on a cache cell is
detected, in an attempt to refresh the contents from memory.  With a
write-thru cache, if a parity error is detected and the dirty bit is
set, you've lost the only copy of the data.

Not a big deal, but worth noticing. 


    Paul K. Rodman 
    rodman@mfci.uucp
    __... ...__    _.. .   _._ ._ .____ __.. ._