Why is MARS mips 32 bit immediate possible?

Question

So, according to a few sources I've looked at, it's not possible to use a 32-bit immediate in 32-bit mips, because machine instructions are 32-bit and immediate values are stored within the machine instructions. As far as I know, the largest an immediate can be is 16-bits, to leave room for the rest of the instruction. But in MARS 4.5 mips, this instruction works fine (using default settings):

.text
ori $t1, $0, 0xffffffff #load 32-bit pattern into $t1

This assembles and runs fine, which baffles me as I think it shouldn't for aforementioned reasons (how can 32-bit machine code hold a 32-bit immediate?). My best guess is ori in MARS actually runs a pseudo-instruction when the immediate field is above 0xffff that lui's and ori's to load regularly, but I'm not sure. Can someone shed some light on this?

Disassemble the binary and see for yourself. Indeed that should not work. Note that some instructions such as addi sign extend the immediate, so addi $t1, $0, 0xffffffff does work. Incidentally, that's an instruction the assembler could have used instead of ori here. — Jester

old_timer old_timer · Accepted Answer · 2017-03-15T03:28:47

If you notice when you assemble that instruction in mars 4.5 you get three instructions

lui $1,0xFFFFFFFF
ori $1,$1,0x0000FFFF
or $9,$0,$1

which is still a bit misleading, but basically it fixes it for you.

Why is MARS mips 32 bit immediate possible?

1 Answers