Question concerning MIPS sign extension

Hi,
I’ve got a question considering the sign and zero extension of immediates of certain instructions.
My first understanding was that if I type for example sltiu $t1 $t2 0xff9c with $t2 containing any random number, the immediate would be sign extended to 0xffffff9c. But apparently that is not the case as it is extended to 0x0000ff9c. This eventually lead me to the conclusion, that, in order to have 0xffffff9c encoded, one would have to write it in this exact way, instead of expecting the assembler to encode it as one wishes to. Which leads me to the question, why we then use the term sign extension if it fills the missing bits of the immediate with zeroes?

Thank you in advance!

Is that in the online MIPS simulator? In MARS sltiu sign-extends and the official documentation says so, too: https://www.cs.cmu.edu/afs/cs/academic/class/15740-f97/public/doc/mips-isa.pdf page 150

Hello Marcel,

I also can not follow you. I’m reasonably sure that you did not enter sltiu $t1 $t2 0xff9c into MARS, because MARS does not actually compile that code, since 0xff9c is out of range.

You can see in the documentation that sltiu takes a 16-bit immediate. Since that immediate is sign-extended, the instruction can take immediates from -2^{15} to 2^{15}-1. 0xff9c is 65436, and 65436 > 2^{15}-1, so it can not be used with that instruction.

We say that the immediate is sign-extended, because this indicates which immediate values can be used. If it were not sign-extended, we could use values from 0 to 2^{16}-1, and 0xff9c would become usable.

I suspect that you actually want the assembler to compare your $t1 with -100, which is 0xffffff9c when encoded as a signed 32-bit number. If you want to do this, you should ask the assembler to do this: If you write sltiu t1 t2 -100, this works, and the 16-bit immediate contains ff9c. If you ask the assembler to compare your number to 0xff9c, it will refuse to assemble your program, since you can not use sltiu to compare something with 0xff9c. You could use sltiu to compare it with 0xffffff9c, but 0xff9c=65436 \neq -100=0xffffff9c.

In general, you want to write your assembler code in such a way that it can easily be read by others (including you if you return to it after a break). Thus, you should always specify the actual value you want to use, instead of relying on sign-extension to alter your value from 0xff9c to 0xffffff9c. The assembler encourages this by refusing to accept out-of-range values.

Hope this explains the way sign-extension works,
Johannes

3 Likes

First of all thank you very much. Yes, I just wanted to correct my question, after some research and understanding. I’m sorry if it caused further confusion. Basically my mistake was it, that I misinterpreted the term ‘sign extended’, which I realised after writing the post. But what I actually intended to ask was what sign extended meant, which you just answered. So again, thank you.

1 Like