> 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 should. 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? -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk
