1

I am currently writing a seminar paper about machine-language and MIPS and when studying the Set on Less Than Immediate Unsigned Instruction I found something weird I don't understand.

The MIPS v5 Documentation (p. 277) states that the 16-Bit Immediate is sign extended before it is compared with the contents of register rs, but is treated as unsigned. That means, and they also state that in the documentation, that you can represent the lower part of an 32-Bit unsigned integer and the upper part of an unsigned integer, with a large gap in between. That makes sense, because your immediate is either prepended by 16 zeros or 16 ones.

Now what I don't quite get is the numbers they provided as an example: They say the lower and upper part of representable unsigned integers is 32,767 large each, which is the highest number representable by 15-Bit. But shouldn't they be 65,535 large each (the largest 16-Bit representable number) because the integers are unsigned and thus the MSB is not used as sign bit?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Lukas Thiersch
  • 155
  • 2
  • 15
  • 2
    You have 16 bits in the instruction. That can only encode 2^16=65536 numbers. Half of those are negative, they go to the top and the other half at the bottom of the range. – Jester Jan 10 '21 at 00:34
  • 2
    The immediate is sign extended from 16 bits to 32 bits, as if a signed 16-bit field (i.e. a negative or positive 16-bit number). Therefore, using positive immediates, we can compare against any number in the range of 0 to 32767. Because the sign extended immediate is ultimately treated as an unsigned number: using negative immediates we can compare against any number in the range of 4,294,934,528 to 4,294,967,295 (the lower bound: 0xFFFF 8000, from 16-bit immediate 0x8000; the upper bound: 0xFFFF FFFF from 16-bit immediate 0xFFFF). – Erik Eidt Jan 10 '21 at 00:52
  • The logic for that instruction TYPE (I-type, R-type...) sign extends the immediate. then AFTER that happens this instruction uses those BITS as unsigned. Do not try to draw any connection between the sign extension and the unsigned use of the bits. It is simply pointing out the obvious that there are a lot of numbers you cannot represent in a single instruction. – old_timer Jan 10 '21 at 15:37

1 Answers1

2

Both ranges are 32768 large, not 7. The full set of 2^16 (65536) encodeable 16-bit immediates is divided in two, the high half having the high bit set, the low half having it cleared.

(The official MIPS documentation is of course correct, saying The representable values are at the minimum [0, 32767] or maximum [max_unsigned-32767, max_unsigned] end of the unsigned range. These are inclusive ranges so they each include 32768 numbers. Counting is important, be careful of off-by-1 errors.)

The encodeable value-ranges are

  • 0x00000000 .. 0x00007FFF (sign-extension produces zeros): lowest unsigned numbers
  • not encodeable; you'll need multiple instructions
  • 0xffff8000 .. 0xffffFFFF (sign-extension produces ones): highest unsigned numbers

(I used lower-case f for the result of sign-extension, upper-case F for parts encoded literally in the immediate.)

For other instructions like slti (not u) that treat the value as signed, these same hex values are still the bit-patterns you can encode, but you interpret them as -32768 (0xffff8000) .. 32767 (0x00007FFF).

Fun fact: MIPS bitwise-boolean instructions like ori zero-extend their immediate so you can construct 0 .. 65535 (0x00000000 .. 0x0000FFFF) in a register with one ori $dst, $zero, imm16 instruction. By contrast, RISC-V always sign-extends immediates.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847