linux-mips
[Top] [All Lists]

Re: GCC 3.4.5 and mftc0

To: Mikael Starvik <mikael.starvik@axis.com>
Subject: Re: GCC 3.4.5 and mftc0
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 14 Dec 2007 16:26:29 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <BFECAF9E178F144FAEF2BF4CE739C6680557B0DB@exmail1.se.axis.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <BFECAF9E178F144FAEF2BF4CE739C6680557B0DB@exmail1.se.axis.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17 (2007-11-01)
On Fri, Dec 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote:

> mftc0() is implemented as
>  
>  .word ...
>   move %0, $1
> 
> With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
> But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
> Implementing this as a or %0, $1, $0 instead gives the expected result.

I wonder what "sumulator" you're using ...

Addu is a perfectly fine implementation of move for 32-bit code.  It's not
for 64-bit code but that's beside the point here.  The or method is also
correct but historically the add instruction has been prefered, also
because some processor - the R4300 afair - processes arithmetic instructions
(add, sub that is not mul / div) faster than logic operations.

> Any suggestions where the problem is and what the correct solution is?

Fix the sumulator.

> After fixing this my next problem is that IPIs doesn't reach all TCs
> correctly (it seams like the code doesn't detect IXMT status correctly,
> but I am still investigating). It is likely that it is caused by
> something similar to the problem above.

The code certainly works on real silicon, so the cause must be something
local to your environment.

Cheers,

  Ralf

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