linux-mips
[Top] [All Lists]

Re: [PATCH] TX49 MFC0 bug workaround

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] TX49 MFC0 bug workaround
From: Sergei Shtylylov <sshtylyov@ru.mvista.com>
Date: Fri, 03 Feb 2006 05:26:48 +0300
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
In-reply-to: <20060202165656.GC17352@linux-mips.org>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060203.013401.41198517.anemo@mba.ocn.ne.jp> <Pine.LNX.4.64N.0602021636380.11727@blysk.ds.pg.gda.pl> <20060202165656.GC17352@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Ralf Baechle wrote:

Workaround: mask EXL bit of the result or place a nop before mfc0.

[...]

@@ -55,8 +56,13 @@ __asm__ (
        "  di                                                      \n"
#else
        "  mfc0    $1,$12                                          \n"
+#if TX49XX_MFC0_WAR && defined(MODULE)
+       "  ori     $1,3                                            \n"
+       "  xori    $1,3                                            \n"
+#else
        "  ori     $1,1                                            \n"
        "  xori    $1,1                                            \n"
+#endif
        "  .set    noreorder                                       \n"
        "  mtc0    $1,$12                                          \n"
#endif

Hmm, wouldn't that "nop" alternative be simpler?

Simpler maybe - but this variant has zero runtime overhead.

And.. how do you imagine placing a NOP (which surely just moves MFC0 down so that it's a 1st insn. on the next page). What if it'll move it to the errata prone address from a safe one instead?

WBR, Sergei

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