# Overflow and the carry flag

*When the answer does not fit*

Overflow is when an arithmetic result does not fit in the available bits. The carry flag (carry out of the top bit) signals it for unsigned numbers, while the overflow flag signals it for signed two's-complement numbers, where the sign bit ends up wrong.

Group: Processor
URL: https://digiwleea.wleeaf.dev/learn/overflow/

An [8-bit adder](https://digiwleea.wleeaf.dev/learn/adder8/) has exactly 8 output bits, but `200 + 100 = 300` needs 9. When a result will not fit in the bits available, that is **overflow**, and the hardware has to flag it so a program knows the answer it just got is incomplete. The twist is that overflow means *two different things* depending on whether you are reading the bits as **unsigned** or as **signed** [two's-complement](https://digiwleea.wleeaf.dev/learn/subtract/) numbers, and the CPU computes a separate flag for each.

## Unsigned: the carry flag

Reading the 8 bits as an unsigned number (`0` to `255`), overflow is simply a **carry out of the top bit**. You already met it as `COUT` on the [8-bit adder](https://digiwleea.wleeaf.dev/learn/adder8/): when the true sum exceeds `255`, a `1` carries off the top, and the 8 result bits hold the sum *modulo 256*. That carry-out is the **carry flag** (`C`). It is the right overflow signal whenever you are doing unsigned arithmetic.

```
200 + 100 = 300 = 1 0010 1100   ->   S = 0010 1100 (44),   carry C = 1
```

> **KEY:** The carry flag does not mean 'the answer is wrong', it means 'the answer wrapped past the unsigned range'. `200 + 100` gives `44` with `C = 1`: read the carry as the 9th bit and the full value `256 + 44 = 300` is recovered. It is the same wrap-around that made [two's-complement subtraction](https://digiwleea.wleeaf.dev/learn/subtract/) work, just observed on the high end.

## Signed: the overflow flag

Now read the very same 8 bits as **signed** two's complement (`-128` to `+127`), where the top bit is the sign. Here a carry out of the top is *not* the right test. Instead, **signed overflow** happens when adding two numbers of the **same sign** produces a result with the **opposite sign**, which is impossible if the true answer fit. The classic case: `+127 + 1`.

```
+127 + 1 = 0111 1111 + 0000 0001 = 1000 0000 = -128   (two positives gave a negative!)
```

Adding two positives can never truly be negative, so that sign flip is the giveaway: the real answer `+128` does not fit in signed 8-bit, which tops out at `+127`. The **overflow flag** (`V`) is `1` exactly in cases like this. Notice that `+127 + 1` produces **no** carry out (`C = 0`) yet **does** signed-overflow (`V = 1`): carry and overflow are genuinely different flags, and which one matters depends on how you chose to read the bits.

> **WARN:** Do not mix up the two flags. **Carry** (`C`) = carry out of the top bit = unsigned overflow. **Overflow** (`V`) = the signed result's sign came out wrong = signed overflow. They can each be `0` or `1` independently: `127 + 1` sets `V` but not `C`, while `200 + 100` (unsigned) sets `C` but, read as signed (`-56 + 100 = 44`), does *not* set `V`. The hardware computes both and lets the program test whichever fits the numbers it meant.

How does hardware detect signed overflow? A neat rule: `V` is `1` when the carry **into** the top bit differs from the carry **out of** it. In gate terms, `V = (carry into bit 7) XOR (carry out of bit 7)`, one [XOR](https://digiwleea.wleeaf.dev/learn/xor/) on two carries the adder already produces. The sign bits agreeing while the carries disagree is precisely the 'two same-sign inputs, wrong-sign output' condition.

```
V = C_into_MSB XOR C_out_of_MSB
```

**Q (Try it):** On the adder/subtractor below (`SUB = 0` to add), compute `100 + 50` two ways. As unsigned numbers, is there a carry out? As signed two's-complement numbers, did signed overflow occur? (`100` and `50` are both well under `127`.)

**A:** `100 + 50 = 150 = 1001 0110`. Unsigned: `150` fits in `0..255`, so there is **no carry out** (`C = 0`), the result `S` reads `150` correctly. Signed: but `150` is past `+127`, and the bit pattern `1001 0110` reads as a **negative** number (`-106`) in two's complement. Two positives gave a negative, so **signed overflow** happened (`V = 1`). Same bits, two readings: unsigned it is fine, signed it overflowed.

_Circuit diagram: The 8-bit adder/subtractor (ADDSUB8) from the subtract lesson, reused to watch overflow. Set SUB = 0 to add. Open it in the lab and try 127 + 1: the sum bits become 1000 0000 (the sign bit S7 flips to 1) with COUT = 0, the signed-overflow case. Then try 200 + 100 and watch COUT go to 1, the unsigned carry case._

> **KEY:** Flags are how arithmetic talks back to the program. The [ALU](https://digiwleea.wleeaf.dev/learn/alu/) already produces a [zero flag](https://digiwleea.wleeaf.dev/learn/alu/); carry and overflow join it as the status bits a CPU tests to make decisions ('did that add overflow?', 'is this unsigned sum too big?'). Together with zero, they are what let conditional logic and comparisons work on top of plain addition.

### FAQ

**Q:** What is overflow in binary arithmetic?

**A:** Overflow is when an arithmetic result does not fit in the available bits. For an [8-bit adder](https://digiwleea.wleeaf.dev/learn/adder8/), any true sum above what 8 bits can hold overflows, and the result bits keep only the low part (the sum modulo 256). The hardware flags it so a program knows the answer is incomplete.

**Q:** What is the difference between the carry flag and the overflow flag?

**A:** The **carry flag** (`C`) is the carry out of the top bit, the overflow test for **unsigned** numbers. The **overflow flag** (`V`) signals **signed** two's-complement overflow, when adding two same-sign numbers yields the wrong sign. They are independent: `127 + 1` sets `V` but not `C`.

**Q:** Why does 127 + 1 equal -128 in two's complement?

**A:** In signed 8-bit two's complement the range is `-128` to `+127`, and `0111 1111` is `+127`. Adding `1` gives `1000 0000`, whose top (sign) bit is now `1`, which reads as `-128`. The true answer `+128` does not fit, so the sign bit overflows: that is signed overflow, flagged by `V = 1`.

**Q:** How does hardware detect signed overflow?

**A:** Signed overflow is `1` when the carry **into** the most-significant bit differs from the carry **out of** it: `V = C_into_MSB XOR C_out_of_MSB`, a single [XOR](https://digiwleea.wleeaf.dev/learn/xor/) on two carries the adder already computes. That condition is exactly 'two same-sign inputs produced a wrong-sign result'.