On Thu, 11 Jul 2002, Gleb O. Raiko wrote:
> Aha, you also stepped on this rake. :-) The problem with IDT manuals
> that they frequently contradict itself. You're right, SW manual allows
> cached flushes, but hardware manuals for the family prohibit this and
> state that flashes must be uncahed.
> (a hw manual on family, the same chapter, the same section :-) )
Wonderful... Add their non-existent support to that. I'm afraid I'll
have to ignore problem reports which involve their processors. :-(
> > Why? I see no dependency. What's the problem with interleaving cache
> > fills and invalidations?
> There're two possible optimization:
> 1. (Requires only the instruction that swaps caches must run uncached)
> CPU may skip implementation of double check of cache hit on loads.
> Scenario: mtc0 with cache swapping with ensuring next instructions are
> in cache
> (pipelining here!); swap occurs; must check again the instructions are
> the cache because the same cacheline in the data cache may have valid
> bit set
> and CPU will get data instead of code.
I can't really see a problem here for proper implementations. The CPU
may have fetched a few instructions beyond the mtc0 doing a cache swap.
It's OK since we didn't modify the code. As long as the swap doesn't
complete, the CPU is using the real I-cache. Once it's completed, it uses
the D-cache. Since the new cache is used in the normal mode of operation,
now tag matches and line replacements occur here as if it was the real
I-cache. No need to do any extra checks at any stage.
> 2. (Requires the whole routine must run uncached)
> CPU may skip check of cache hit on loads from an isolated cache.
But the other cache isn't isolated -- IsC only works on the cache that
plays the role of the D-cache.
> i don't know what optimization IDT made, perhaps, number 3. But, 1. is
> really worth to implement.
It's possible they broke something, simply.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +