The MIPS R4000 has the usual collection of arithmetic operations, but the mnemonics are confusingly-named. The general notation for arithmetic operations is <\/p>\n
\n OP destination, source1, source2\n<\/pre>\nwith the destination register on the left and the source register or registers on the right. <\/p>\n
Okay, here goes. We start with addition and subtraction. <\/p>\n
\n ADD rd, rs, rt ; rd = rs + rt, trap on overflow\n ADDU rd, rs, rt ; rd = rs + rt, no trap on overflow\n SUB rd, rs, rt ; rd = rs - rt, trap on overflow\n SUBU rd, rs, rt ; rd = rs - rt, no trap on overflow\n<\/pre>\nThe
ADD<\/code> andSUB<\/code> instructions perform addition and subtraction and raise a trap if a signed overflow occurs. TheADDU<\/code> andSUBU<\/code> instructions do the same thing, but without the overflow trap. TheU<\/code> suffix officially means “unsigned”, but this is confusing because the addition can be performed on both signed and unsigned values, thanks to twos complement. The real issue is whether an overflow trap is raised. <\/p>\nThere are also versions of the addition instructions that accept a 16-bit signed immediate as a second addend: <\/p>\n
\n ADDI rd, rs, imm16 ; rd = rs + (int16_t)imm16, trap on overflow\n ADDIU rd, rs, imm16 ; rd = rs + (int16_t)imm16, no trap on overflow\n<\/pre>\nNote that the
U<\/code> is double-confusing here, because even though theU<\/code> officially stands for “unsigned”, the immediate value is treated as signed, and the addition is suitable for both signed and unsigned values. <\/p>\nThere are no corresponding
SUBI<\/code> orSUBIU<\/code> instructions, but they can be synthesized: <\/p>\n\n ADDI rd, rs, -imm16 ; SUBI rd, rs, imm16\n ADDIU rd, rs, -imm16 ; SUBIU rd, rs, imm16\n<\/pre>\n(Of course, this doesn’t work if the value you want to subtract is −32768, but hey, it mostly works.) <\/p>\n
The next group of instructions is the bitwise operations. These never trap.¹ <\/p>\n
\n AND rd, rs, rt ; rd = rs & rt\n ANDI rd, rs, imm16 ; rd = rs & (uint16_t)imm16\n OR rd, rs, rt ; rd = rs | rt\n ORI rd, rs, imm16 ; rd = rs | (uint16_t)imm16\n XOR rd, rs, rt ; rd = rs ^ rt\n XORI rd, rs, imm16 ; rd = rs ^ (uint16_t)imm16\n NOR rd, rs, rt ; rd = ~(rs | rt)\n<\/pre>\nNote the inconsistency: The addition instructions treat the immediate as a signed 16-bit value (and sign-extend it to a 32-bit value), but the bitwise logical operations treat it as an unsigned 16-bit value (and zero-extend it to a 32-bit value). Stay alert! <\/p>\n
The last group of instructions for today is the shift instructions. These also never trap. <\/p>\n
\n SLL rd, rs, imm5 ; rd = rs << imm5\n SLLV rd, rs, rt ; rd = rs << (rt % 32)\n SRL rd, rs, imm5 ; rd = rs >>U imm5\n SRLV rd, rs, rt ; rd = rs >>U (rt % 32)\n SRA rd, rs, imm5 ; rd = rs >> imm5\n SRAV rd, rs, rt ; rd = rs >> (rt % 32)\n<\/pre>\nThe mnemonics stand for “shift left logical”, “shift right logical” and “shift right arithmetic”. The
V<\/code> suffix stands for “variable”, and indicates that the shift amount comes from a register rather than an immediate. <\/p>\nYup, that’s another inconsistency. Following the pattern of the addition and bitwise logical groups, these instructions should have been named
SLL<\/code> for shifting by an amount specified by a register andSLLI<\/code> for shifting by an amount specified by an immediate. Go figure. <\/p>\nThere are no built-in sign-extension or zero-extension instructions. You can get zero-extension in one instruction by explicitly masking out the upper bytes: <\/p>\n
\n ; zero extend byte to word\n ANDI rd, rs, 0xFF ; rd = ( uint8_t)rs\n\n ; zero extend halfword to word\n ANDI rd, rs, 0xFFFF ; rd = (uint16_t)rs\n<\/pre>\nSign extension requires two instructions. <\/p>\n
\n ; sign extend byte to word\n SLL rd, rs, 24 ; rd = rs << 24\n SRA rd, rd, 24 ; rd = (int32_t)rd >> 24\n\n ; sign extend halfword to word\n SLL rd, rs, 16 ; rd = rs << 16\n SRA rd, rd, 16 ; rd = (int32_t)rd >> 16\n<\/pre>\n<\/p>\nAnd I’m going to mention these instructions here because I can’t find a good place to put them: <\/p>\n
\n SYSCALL imm20 ; system call\n BREAK imm20 ; breakpoint\n<\/pre>\nBoth instructions trap into the kernel. The system call instruction is intended to be used to make operation system calls; the breakpoint instruction is intended to be used for software breakpoints. Both instructions carry a 20-bit immediate payload that can be used for whatever purpose the operating system chooses. <\/p>\n
Here are some more instructions you can synthesize from the official instructions: <\/p>\n
\n SUB rd, zero, rs ; NEG rd, rs\n SUBU rd, zero, rs ; NEGU rd, rs\n ADDU rd, zero, rs ; MOVE rd, rs\n OR rd, zero, rs ; MOVE rd, rs\n NOR rd, zero, rs ; NOT rd, rs\n SLL zero, zero, 0 ; NOP\n SLL zero, zero, 1 ; SSNOP\n<\/pre>\nThere are many possible ways of synthesizing a
MOVE<\/code> instruction, but in order to be able to unwind exceptions, Windows NT requires that register motion in the prologue or epilogue of a function must take one of the two forms given above. <\/p>\nSimilarly, there are many ways of performing a
NOP<\/code>. Basically, any non-trapping 32-bit computation that targets the zero<\/var> register is functionally a nop, but the two above are treated specially by the processor. <\/p>\n\n
NOP<\/code> =SLL zero, zero, 0<\/code> is special-cased by the processor as a nop that can be optimized out entirely. Use it when you need to pad out some code for space. <\/li>\nSSNOP<\/code> =SLL zero, zero, 1<\/code> is special-cased by the processor as a nop that must be issued, and it will not be simultaneously issued with any other instruction. Use it when you need to pad out some code for time. (TheSS<\/code> stands for “super-scalar”.) <\/li>\n<\/ul>\nThe encoding of
SLL zero, zero, 0<\/code> happens to be0x00000000<\/code>, which I’m sure is not a coincidence. I’m not convinced that it’s a good idea, though. I would have chosen0x00000000<\/code> to be the encoding of a breakpoint or invalid instruction. <\/p>\n