RE: Bad MIPS address arithmetic

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Wed, 12 May 2010, Paul Koning wrote:

> The code produces ffffffff8000nnnn in v0.  With 64 bit address
> arithmetic, the memory reference to -25536(v0) produces an address of
> the form ffffffff7fffnnnn which is what causes the trouble.  I take it
> from what you're saying that setting PX and clearing UX will cause the
> processor to ignore the upper 32 bits in that address calculation and
> instead use the sign extended lower 32 bits, so I get 000000007fffnnnn
> which is the right answer.  Section 4.9 in the MIPS64 spec volume 3
> describes this reasonably clearly.

 I believe this is the case although I haven't verified it empirically 
(technically, this should be the equivalent of what ADDIU does on a 64-bit 
processor, even though a separate adder will be used in the address 
generation path; likewise I wouldn't blame a CPU implementation if it did 
something unpredictable if the base contained in the register was not a 
properly sign-extended 32-bit number before offsetting).

> My kernel is currently setting UX (it doesn't have a symbolic name for
> PX at all) but my platform does support PX so that seems like the
> simplest solution.  Alternatively, I can move the initial SP, that isn't
> all that hard either.

 Please note that clearing UX has a side effect of using the TLB Refill 
exception vector rather than the XTLB Refill one.  The MMU register state 
prepared for the handler remains the same so it's up to the kernel to take 
advantage of this distinction or not, but anyway it has to take it into 
account somehow.

> Thanks for the help.

 You are welcome.

  Maciej