> > Yes, the code fragment in question is R4K-specific, but
> > we really need to migrate towards the use of consistent
> > mechanisms that work across the full range of MIPS
> > CPUs. Ideally, *all* CP0 hazards should some day be
> > padded out with "ssnops" (sll $0,$0,1, if I recall), which
> > force a 1 cycle delay per instruction even on superscalar
> > MIPS CPUs.
>
> While we could come up with a common TLB fault handler I really don't want
> to. For many applications this TLB fault handler is extremly performance
> sensitive; every single cycle directly translates into application
> performance. Seems like we'll need some more TLB fault handler. And a
> complete TLB fault handler rewrite would be a good ide anyway, sigh ...
Sorry if I wasn't clear. I am not suggesting a "one size
fits all" TLB handler - though as the old SGI hardware
gets retired and the newer, more standardized MIPS32
and MIPS64 parts become the principal targets, we
may see a greater convergence. I am simply suggesting
that, even if there are differences in policy necessitated
by different CPU implementations, they should use the
same mechanisms. If all CP0 hazards are avoided by
using ssnops, for example, we could evolve from writing
a new handler for every R4K variant to having a routine
that generates a handler with the right pipeline hazard
management, based on a set of paramters for the CPU.
And, while Ralf and I sometimes disagree on the importance
of this, in my own opinion, being consistent in these small
details helps avoid errors when a systems programmer
new to the architecture and/or the OS needs to work on
the system.
You may say that I'm a dreamer, but I'm not the only one. ;-)
Regards,
Kevin K.
