[Top] [All Lists]

Re: load_unaligned() and "uld" instruction

To: "Kevin D. Kissell" <>
Subject: Re: load_unaligned() and "uld" instruction
From: Jun Sun <>
Date: Sat, 07 Oct 2000 00:16:02 -0700
References: <> <> <> <000d01c02782$32d31560$0deca8c0@Ulysses> <> <> <> <00d101c02f04$3a6d7340$0deca8c0@Ulysses> <> <> <> <00e201c02fd6$9964c9c0$0deca8c0@Ulysses>
"Kevin D. Kissell" wrote:
> Jun Sun wrote:
> > That is what the manual claims.  However I did find something strange.
> >
> > I run the following code on R5432:
> >
> > 0x8019dc34 <my_get_unaligned+4>:        ldl     $a2,7($a0)
> > 0x8019dc38 <my_get_unaligned+8>:        ldr     $a2,0($a0)
> > 0x8019dc3c <my_get_unaligned+12>:       srl     $a2,$a2,0x10
> >
> > As Kevin has guessed, it actually runs fine.  However, the register
> > content in $a2 is not right.  Basically it appears that $a2 is a 32-bit
> > register instead of 64-bit register.  I put a srl instruction to make
> > sure I was not fooled by gdb.
> Please read the instruction manual for srl more closely.
> In order to preserve binary compatibility with 32-bit MIPS
> CPUs, srl, sll, and sra always work *as if* only a 32-bit register
> is implemented.  If you want to shift the full 64 bits, you need
> to use explicit 64-bit shifts: dsrl, dsll, dsra, etc.  Use a dsrl
> instead of an srl and you *may* see what you are expecting.

Just re-did the test with dsrl.  It does show that the higher 32-bit are
loaded correctly by ldl/ldr.  The result still was not completely right,
due to the inline assembler bug noted by Ralf earlier.  That bug casts
off the higher 32-bit upon the function return.

Thanks, Kevin.


... learn something new each day ...

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