What is the “relationship” between addi and subi?

Question

I'm supposed to answer this question. After some research it says that add and sub have the same opcode and differ only in the functional field. Is this the answer or something else?

Update

It's available in the Nios II CPU manual:

subi
subtract immediate
Operation: rB ← rA – σ (IMMED)
Assembler Syntax: subi rB, rA, IMMED
Example: subi r8, r8, 4
Description: Sign-extends the immediate value IMMED to 32 bits, subtracts it from the value of rA and then
            stores the result in rB.
Usage: The maximum allowed value of IMMED is 32768. The minimum allowed value is
–32767.
Pseudo-instruction:
© March 2009
subi is implemented as addi rB, rA, -IMMED

Answer 1

I'm unaware that MIPS even has a proper subi instruction (though some environments may implement a macro for it).

Since you're subtracting an immediate value, you can just provide the negation of it to the addi instruction:

addi $r1, $r2, -42     ; equivalent to subi $r1, $r2, 42

The immediate operand is a two's complement value which means it's perfectly capable of being a negative number and the way that two's complement works means that you can add a negative number in an unsigned manner and that gives the same result as subtracting (since you wrap around).

For example, -42 in 16-bit two's complement is the unsigned value 65494. When you add 50 and 65494 wrapping around at 65536, you end up with:

     50
+ 65494 (ie, -42)
  -----
  65544 (overflow, so
- 65536  we wrap at 64K)
  -----
      8 (identical to "50 - 42")

Answer 2

At the hardware / machine-code level of ISA design, MIPS doesn't have a subi / subiu instruction. That makes sense because MIPS doesn't have a FLAGS register.

There's no carry flag that would record the difference between adding a negative or subtracting a positive, like there is on many other architectures (x86, ARM, and many other less RISCy architectures). Thus spending an extra opcode (and the transistors to decode it) makes no sense.

Adding a negated immediate doesn't change the signed-overflow detection of addi / subi. You get signed overflow when you add two numbers with the same sign and the result has the opposite sign. Or when subtracting z = x - y, if x and y have opposite signs, and z and x have opposite signs, that's subtraction overflow (where you want subi to trap.) y is the immediate, so implementing it as z = x + y_negated makes addi's overflow-detection work.

Of course normally you (or a C compiler) would just use addiu / subiu because you don't want to trap, and would rather have wrap-around as the signed-overflow behaviour, unless you compiled with -fsanitize=undefined-behavior or something.

---

At the asm source level, it can be implemented as a pseudo-instruction for convenience, as your quote from the NIOS II manual shows. (Or even as a macro, on assemblers that don't support the pseudo-instruction.)

The only time when a hardware subi / subiu would save an instruction is when you wanted to add 32768 / subtract -32678. (Notice the NIOS II manual pointing out that subi supports immediates in the -32767 .. 32768 range, opposite from the normal signed 16-bit 2's complement -32768 .. 32767)

The most-negative number in 2's complement is an anomaly, and its negative takes an extra bit to represent correctly. i.e. -(0x8000) overflows to 0x8000 in the 16-bit immediate. Any decent assembler that implements subi as a pseudo-instruction should warn about this, or warn about using an immediate outside the signed-16-bit range for addi / addiu.

---

addiu sign-extends its immediate to 32 bits, the same as addi. The "unsigned" is a misnomer. Why would we use addiu instead of addi?. Signed and unsigned addition are the same binary operation for 2's complement machines. The naming kind of matches C signed-overflow being undefined behaviour, but note that undefined doesn't require faulting. Think of addi as overflow-checked signed addition, and only use it when you specifically want that.

Fun fact: ori and other booleans do zero-extend their immediate, so li $t0, val can expand to only a single instruction for val = -32768 .. 65535, using either addiu $t0, $zero, signed_int16 or ori $t0, $zero, uint16.

Answer 3

Agree with above. Expound on some environments. Put forth the little truth I've seen on the matter. Develop my own (conspiracy) theory.

The keyword is down there in that second to last line (3rd, including copyright)- its a pseudo instruction. This is always a common class question, so its worth making it clear. Some emulators (Looking at you Mars) treat it as a true instruction, while others (qtspim - shame!) won't even bother to compile it.

While I've never found a great example, supposedly its that it's too simple to convert one to the other, so it's redundant. And they were trying to follow "simple design principles". To me, this breaks down a bit, because there are plenty of pseudoinstructions already that represent simple reworkings of other commands. The branch pseudo instructions break down into 2 commands, and this would take 2 or even 3 commands. So, this one is no different. And what about things like "li". I mean, come on, thats just addiu. Nothing else. If they add that, there's seriously no excuse. Honestly, I think it'd be easier to add it for simplicity and symmetry sake. But then, what would happen to everyone's favorite MIPS exam question?

And that's the real reason there's no SUBI. For stodgy old ASM programmers to screw with undergrads.