🚀 go-pugleaf

In article <11402@pasteur.Berkeley.EDU> carlton@betelgeuse (Mike Carlton) writes:

>I agree that the MIPS scheme is nice, but it does have its drawbacks.  In
>particular, they've fixed the cache control.  If they got it right (for your
>application) then no problem.  Otherwise you're out of luck.  It would be
>possible to make some of the details configurable, but I believe that MIPS 
>doesn't allow this.
Actually, R3000s allow a fair amount of flexibility.
1) I & D-caches can have different sizes.
2) The number of words refilled into the cache upon cache miss is settable
from 1 to 32 words.
3) You can use instruction-streaming, or not.
4) You can cause partial-word writes to invalidate the corresponding cache
word, or cause it to do a read-modify-write.

>If I remember right (somebody borrowed my MIPS book so I can't verify), the 
>MIPS cache control requires a write-through cache.  Personally, I don't want 
>a write-through cache.  Another aspect is the write latency (i.e. how many 
>cycles does your cache take to handle a write-hit?).  I think the MIPS 
>controller assumes a single cycle.  This implies you've got to build a cache
>to handle this, and this will get trickier when you can buy a 40 or 50MHz MIPS.

The first-level cache is a write-thru cache.  People often build 2nd-level
caches to be write-back for multi-processors.  It does expect single-cycle
caches;  it will get trickier.  Of course, the higher clock rates, sooner or
later, require everybody doing CMOS/BiCMOS micros to build integrated
"superchips" anyway if they want to be competitive.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086