[Top] [All Lists]

Re: [patch] MIPS64 R4k TLB refill CP0 hazards

To: Carsten Langgaard <>
Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards
From: "Maciej W. Rozycki" <>
Date: Tue, 30 Jul 2002 14:44:32 +0200 (MET DST)
Cc: Ralf Baechle <>,,
In-reply-to: <>
Organization: Technical University of Gdansk
On Tue, 30 Jul 2002, Carsten Langgaard wrote:

> > The branch - which is used by other OSes btw. - for the R4000 / R4400 where
> > this kind of taken branch implies a total delay of three cycles.  One for
> > the branch delay slot plus two extra cycles for the killed instructions
> > 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.
> If we are going to make the exception generic and usable for as many CPUs as
> possible, I don't thing the branch trick is save.
> Why not make a hazard barrier that contains 0, 1 or 2 'ssnop's depending on
> the CPU configuration ?
> This way we will have the exact number of 'ssnop' to solve the hazard, without
> adding extra penalty for other CPUs.

 Since the handler is critical for performance, it would be desireable to
have separate versions tuned for particular CPUs.  The branch for the
R4400 seems appropriate as it works unlike the documented code: the
R4000/R4400 manual as available from the MIPS site states a single
intervening instruction is needed before the last move to EntryLo and a
"tlbwr" or "tlbwi" (see Table F-1 and F-2).  So I conclude the branch is
really a workaround for a kind of erratum or a specification change. 

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>