On Tue, Jul 30, 2002 at 02:39:24PM +0200, Kevin D. Kissell wrote:
> > following the branch delay slot. For R4600, R4700, R5000 and a bunch of
> > derivates I've verified that according to the documentation this extra
> > penalty of two cycles does not exist nor we need two extra cycles to handle
> > the hazard. In other words the branch trick - which also is used by
> > some other commercial OS btw. - is providing best possible performance on
> > a wide range of processors.
>
> Which would be a fairly compelling argument if (a) we were constrained
> for some reason to only have one handler and (b) the majority of MIPS
> Linux systems being built had R4000/4400/4600/4700/5000 CPUs in
> them. But neither of those assumptions is true. I don't see any cases
> in the kernel of assembler functions being put into the .init segment of
> the kernel image, but I would think that it could be (and anyway should
> be) done with the various exception vectors, and in any case they are
> dynamically installed based on the detected CPU. If people using
> old workstations want to use a branch-based timing hack in their
> TLB handlers, that's all well and good. But there is no guarantee that
> the trick will work on all future (or even current) MIPS CPUs, and
> I agree with Carsten that it is inappropriate for the generic or default
> MIPS32 handlers. I guess we need to propose a patch to allow
> the Indy/Decstation crowd to retain their branch-based scheme,
> but to quarantine it from the rest of the MIPS/Linux universe.
Basically we have two groups of interrupt handlers. Some contain
workarounds for hardware bugs; the rest are very similar except having
to handle different hazards. I was already thinking about building the
actuall exception handlers from a piece of code that inserts the right
number of (ss)nops etc. as required into the right place, thereby
producing an optimal handler for every CPU.
Ralf
|