Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96

["Maciej W. Rozycki" <macro@ds2.pg.gda.pl>]

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
> in 
> 	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: macro@ds2.pg.gda.pl, PGP key available        +