7

Is there is a standard or recommendation for how the addi instruction (and others) should be interpreted in assembly, when hexadecimal immediate values are used?

Example:

addi $t0, $zero, 0xffff

I was expecting this to mean the same as addi $t0, $zero, -1 where 0xffff would be sign extended to 0xffffffff, as is done by the processor, but was surprised by the fact that the assembler of the Mars simulator interprets hexadecimals as 32bit unsigned numbers and tries to do addi $t0, $zero, 0x0000ffff as a pseudo-instruction (if pseudo-instructions are enabled).

To be clear, MARS's assembler assembles that addi $t0, $zero, 0xffff pseudo-instruction to multiple machine instructions which create that constant (65535 = 0xffff) in a register and then add it, if pseudo-instructions are enabled. MARS's simulator simulates instructions like 0x2008ffff (addi $t0, $zero, -1) correctly.

The SPIM assembler just aborts with an error.

What I would like to know is if assemblers always interpret this way, and if there is someplace where this is written or explained as I could not find anything.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Miguel
  • 658
  • 1
  • 6
  • 19
  • 1
    Assemblers usually interpret hexadecimal immediates as unsigned constants. – gusbro May 11 '16 at 13:58
  • This is why there is a `subi` instruction. – markgz May 11 '16 at 16:55
  • @markgz There is no `subi` instruction in MIPS. – Miguel May 11 '16 at 23:55
  • Whoops! My memory failed on that one. – markgz May 12 '16 at 21:34
  • That would seem to be a simulator bug -- the MIPS instruction set spec is clear that the addi instruction sign-extends the 16-bit immediate in the instruction. – Chris Dodd Jul 31 '19 at 22:48
  • 2
    @ChrisDodd: That's not a bug. `0xffff` is not representable as a 16-bit sign-extended integer, and asm source normally uses full 32-bit constants like `-1`, not just the bit-pattern for the immediate. What's surprising to me is that `clang -target mips` assembles it to `0x2008ffff` (i.e. `addi $t0, $zero, -1`) without even a warning about the value not fitting in an immediate, like NASM does for `add rcx, 0xffffffff`, the equivalent situation for x86-64 with 64-bit add of a 32-bit immediate. : `warning: signed dword value exceeds bounds [-w+number-overflow]` – Peter Cordes Aug 01 '19 at 02:28
  • 0xFFFF != 0xFFFFFFFF – old_timer Mar 22 '20 at 15:21
  • There are several assemblers for MIPS, so it depends on the assembler. – Erik Eidt Jul 10 '22 at 00:40

0 Answers0