Overflow/carry flag in MIPS

Question

I have searched a bit and didn't find anything that properly explained this.

In MIPS you have add and addu to do additions. The main difference is that addu doesn't generate an overflow exceptions.

Let's say we have this binary (I'm using four bits although MIPS is 32 for simplification):

0111

If we add 1 it becomes 1000.

With the add instruction there is an overflow and no carry, since a positive 7 became a negative 1 (assuming two's complement in MIPS). This generates an overflow exception too.

With the addu there is no overflow and no carry, since everything went as expected.

Now let's say you have this binary:

1111

If we add 1 it becomes 0000.

With the add instruction there should be no overflow since a negative 1 became a 0. What about the carry out flag, does it change to 1?

And what happens with the addu instruction? Is it considered overflow, since 15 became 0? I know that there is no overflow exception, but what happens to the overflow flag? Does it get set to 1? What about the carry flag?

Answer 1

There is no carryout flag in MIPS architecture.

Overflow exception in the case of addition happens when the sign of the result is different form the expected sign which can happen:

• When you add two positive numbers and you get a negative number as a result
• When you add two negative numbers and you get a positive number as a result

So yes, in your hypothetical 4 bit MIPS 0111+1 results in an overflow, with the corresponding flag being activated.

Answer 2

I googled a bit and found this useful.

(I think) This explained why there aren't carry bits in MIPS.

https://yarchive.net/comp/carry_bit.html

A quick summary: MIPS' goal is to simplify implementations, while carry bits can make things much more complex especially in more aggressive (pipeline / superscalar / speculative & out-of order) designs.

In a simple pipelined design, each result is written back to its target register, and the result is normally made available via a bypass network, in case it is immediately needed by the next instruction.

If you take a typical current RISC and include "add-with-carry", for instance (and this is certainly doable), the irregularity definitely adds complexity, and the carry bit can become a bottleneck in more aggressive implementations, as operations that either set it or test it become serialized on it , and also require extra hardware (comparators & muxes) in an awkward place. (See H&P: look up bypassing & condition codes in the index).

As the CPU becomes superscalar, the extra logic for checking for dependencies gets worse: implementors especially hate irregularities.

As it becomes speculative & out-of order, a typical design would require not just a register-rename unit, but a "carry-bit-rename-unit", as there is no such thing as "The carry bit", but rather an independent set of carry bits, with appropriate rename logic to select the correct carry bit set by the logically most recent instruction that sets the bit.