On Tue, 13 Jul 2004, Kevin D. Kissell wrote: > > That's a new restriction in MIPS32 v2.0 and you're right, we're not trying > > to deal with it yet except for the TX49xx. > > I'm pretty sure that restriction is not new to MIPS32 v2.0. In any The restriction was apparently added in revision 1.00 of the MIPS32 architecture vol.II document. I don't have that revision -- I have versions 0.95 and 2.00 only -- without looking at the revision history in 2.00 I'd expect the original MIPS32 spec not to enforce such a restriction, either. > case, there are pre-MIPS32/MIPS64 chips in current mass production > and use, under Linux among other OSes, which specify in their user > manuals that one should not invalidate the Icache line from which one > is currently executing. The clause about unpredictable behavior in > that case went into the MIPS32 spec because it was known that such > parts existed, and we wanted to make it as easy as possible for such > designs to be made compliant Ugh, although I can imagine valid arguments for such a decision. > Invalidating the entire Icache with a routine executing out of the Icache > is a Bad Idea, and will almost certainly cause problems some of the time > on some MIPS processors. Reasonable people could disagree on whether > we want to handle that in the generic code, or create a variant icache flush > routine which gets plugged in only for those parts that really need it. As executing code from an uncached space is terribly slow, there are at least two points of optimization: 1. The Icache invalidation handler should run cached on processors known to handle it gracefully. 2. For others, as you suggest, it should attempt to figure out whether its code may invalidate itself and run uncached then, perhaps for the problematic lines only. Maciej
