On Thu, 11 Jul 2002, Gleb O. Raiko wrote:

quoted

But that code belongs in the R30xx specific cache routines, not in the MIPS32 cache
routines.

I don't wonder if other IDT CPUs also require this, including those that
conform MIPS32.

 Well, for r3k it may seem somewhat justified as cache flushing requires
cache isolation.  But the IDT manual for their whole family of processors
claims the D-cache can function as an I-cache (when swapped; doesn't
apply when not, obviously) and cache flushing can run from KSEG0.

 See "IDT MIPS Microprocessor Family Software Reference Manual", chapter 5
"Cache Management", section "Invalidation":

 "To invalidate the cache in the R30xx:
[...]
 The invalidate routine is normally executed with its instructions
cacheable.  This sounds like a lot of trouble; but in fact shouldnt
require any extra steps to run cached. An invalidation routine in uncached
space will run 4-10 times slower."

That's right as the IsC bit only isolates the D-cache (either the real one
or the I-cache, when swapped) and not the I-cache, so no need to waste
cycles running uncached as the I-cache works normally. 

Basically, requirement of uncached run makes hadrware logic much simpler
and allows  to save silicon a bit.

 Why?  I see no dependency.  What's the problem with interleaving cache
fills and invalidations?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +