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?
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.