[Top] [All Lists]

Re: unaligned load in branch delay slot

To: Ralf Baechle <>
Subject: Re: unaligned load in branch delay slot
From: "Maciej W. Rozycki" <>
Date: Tue, 28 Jan 2003 13:30:03 +0100 (MET)
Cc: Geert Uytterhoeven <>, Mike Uhler <>, Linux/MIPS Development <>
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
On Tue, 28 Jan 2003, Ralf Baechle wrote:

> Hmm...  If you can't reproduce this anymore I guess we should pull this
> patch again?  Despite Mike basically acknowledging that such behaviour
> exists I don't feel to well about applying patches for non-reproducable
> processor behaviour and would rather prefer to wait until we believe to
> know the full details.

 Agreed, and I believe a run-time check would be better (and trivial as
well).  The (!MIPS32 && !MIPS64) approximation is too rough.

> > I think you can remove the unconditional jumps, cfr. Mike's comments.
> That's one of the points where I felt a bit unsafe about the extend of
> the issue so I left the jumps in.  Anyway, why should it make a difference
> if an instruction is conditional or not?

 I think jumps cannot be non-taken... 

> > Isn't the Vr4120A core MIPS32?
> Vr4120 is MIPS III.

 Actually I have a datasheet for the Vr4121 (which is a Vr4120 plus some
glue logic for specific peripherals) and it explicitly states whenever
cp0.EPC points to a preceding branch/jump of a faulting instruction, the
cp0.Cause.BD bit is set.  Maybe there is an errata sheet available.

 Additionally the processor is "nice" enough to implement the MIPS III ISA
(with the MIPS16 extension) except ll/sc, lld/scd, sigh...  So the
emulation would need to be ported to the 64-bit kernel if we were to
support this processor in the 64-bit mode. 

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

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