> Well, docs state only the cache that acts as the D-cache gets isolated
> and the one that acts as the I-cache always functions normally (and the
> real D-cache has all the logic needed to pretend it's an I-cache
> successfully). Thus running from an uncached space is not needed. I
> haven't checked it explicitly, but the flushing functions would fail
> (hang) quite soon otherwise and they don't.
I wrote the IDT software manual (I later used bits of it as the basis
of parts of "See MIPS Run".) Of course, every word of it is true. I
can't comment on IDT's hardware manuals, though in my experience they
were somewhat better than the average.
Algorithmics produced cached routines to manipulate R3000-style caches
and they work reliably; what's more, the hardware specs say they
Yes, it seems a bit strange to run with 'isolated'; but 'isolated'
really only stops loads and stores from reading/writing at the bus
interface. It's use in cache functions was an accident; the original
R2000 caches did not support partial-word writes and could be
invalidated just by writing a byte to them. When this was discovered
to be unacceptable, the 'isolated' bit (intended for diagnostics) was
pressed into service.
It is extraordinarily inefficient to run invalidate or writeback
routines uncached. It will add perhaps 4-10 instruction fetches
(external memory reads) for each cache line invalidated; that's
probably double the memory overhead of the DMA operation which
necessitated the invalidation. That's something production-quality
code shouldn't do.
PS: my standard appeal. When you say you 'flush' a cache do you mean
invalidate, write-back, or both? If (as I suspect) not all of you
mean the same thing, should you not instead speak of 'invalidate' and
'writeback'... sloppy language surely leads to sloppy programming?
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205