On Thu, Jul 11, 2002 at 08:19:55AM +0200, Kevin D. Kissell wrote: > Excuse me, but I've seen this statement used by others in > the past as an excuse for doing something silly or not doing > something reasonable, and it generally hasn't washed. > In what specific cases have the CP0 pipeline hazards > changed between minor revisions of any production > MIPS CPU? The *documentation* may have been > corrected, but these hazards are fairly fundamental > artifacts of the pipeline microarchitecture of a given > processor. Ancient TLB exception handler code was assuming out of order execution of the instruction stream in cp0 based on the documentation in appendix H of the R4400 manual, version 2. I wrote that code for a R4400 version 5.0 and it was running fine on R4000 3.0 but somebody found it to break on R4000 version 2.2. At least that are the details as I remember them. I don't blame MIPS (well, probably SGI at that time ...) for not documenting these details perfectly right for each and every R4[04]00 implementation. The code broken was written extremly aggressivly and eventually had to be changed anyway for the sake of other processors. > The CP0 hazard between a write of EntryHi > and a subsequent TLBWI instruction is flagged > in the MIPS32 spec and noted as being "typically" > 2 cycles. I'm not going to spend the time going > through my full set of users manuals, but a representative > sampling shows this hazard as being specified for > every R4xxx and R5xxx CPU I checked. The fact > that a given CPU *may* get away with it is no > excuse for not protecting common code. No argument about this one. We definately were lucky. > I note that Ralf has, in fact, applied the fix to the > OSS CVS repository. I also note that "BARRIER" > is still defined to be a string of 6 nops. I would argue > (again) that those really, really ought to be ssnops, > and that if they *were* ssnops, one could probably > have fewer of them. I've applied it because I think the whole update_mmu_cache implementation is ready for a reimplementation anyway. On the performance this isn't going to have measurable impact anyway as update_mmu_cache is only being called once per page fault. BARRIER is defined as 6 nops since it was written somewhen during the summer '96. By that time Linux didn't yet support any processor that was featuring ssnop, so 6 nops certainly were too paranoid. These days you're certainly right, ssnops are the way to go, especially because they don't have any negative impact on pre-ssnop implementations. Ralf
