13. Overflow: When the Answer Doesn't Fit

The concept

Lessons 11 and 12 established one plain rule for addition and subtraction alike: add the two 8-bit patterns, and if a 9th bit appears, discard it. That rule is always safe as long as the true mathematical answer actually fits in 8-bit two's complement — the range -128 to 127. Discarding the 9th bit there isn't a loss; it's just ordinary wraparound giving back exactly the right answer, the same way it has since Lesson 2.

But sometimes the true answer doesn't fit in that range at all — more than 127, or less than -128. No amount of correct bit manipulation can produce a pattern for a value the encoding has no room for; whatever pattern comes out instead decodes to some other, wrong value. This is overflow, and it's a completely different event from the 9th-bit carries Lessons 11-12 already discard as routine.

Overflow can only happen in one situation: when the two operands being added share the same sign — both non-negative, or both negative. Here's why. If one operand is positive and the other negative, the true sum always lands strictly between them: adding a negative number can only pull the result down from the positive operand, and adding a positive number can only push it up from the negative operand. Both operands already fit inside -128 to 127 (they're valid 8-bit words), so a sum trapped between two values that both fit must also fit. Opposite-sign addition can never overflow, no matter how close to the edges the operands are.

Same-sign addition has no such guarantee — two positives can sum past 127, and two negatives can sum past -128. The detection rule: if both operands share a sign, but the result's sign bit doesn't match that shared sign, overflow happened — the result is wrong, not just wrapped, and should be discarded rather than trusted.

This is worth stating plainly because it's easy to conflate with Lessons 11-12's 9th-bit carry: they are independent checks, and neither predicts the other. A carry out of the top bit can occur with no overflow at all (Lesson 11 Example 4's -5 + -3 produces a carry, and the answer is still the correct -8). Overflow can just as easily occur with no carry produced (see Example 1 below). Checking one tells you nothing about the other — both same-sign-operands-vs-result-sign is the only rule that actually detects overflow.

For Lesson 12's subtraction (a - b = a + (-b)), the rule applies to the transformed operands: check the signs of a and -b (not a and b), since that's the addition actually being performed under the hood.

Example 1 — Two positives overflowing: 100 + 100

0110 0100   (+100)

• 0110 0100 (+100)

1100 1000   <- no 9th bit this time

No carry was produced, so there's nothing to discard — but that doesn't mean the answer is right. Both operands are positive (sign bit 0), and the result's sign bit is 1. Same-sign operands, mismatched result sign: overflow. Decoding 1100 1000 gives -56 — nowhere close to the true answer. 100 + 100 = 200, and 200 simply doesn't fit in 8-bit two's complement's -128 to 127 range; no bit pattern exists for it.

Example 2 — Two negatives overflowing: -70 + -70

1011 1010   (-70)

• 1011 1010 (-70)

1 0111 0100 <- a 9th bit, discarded exactly per Lessons 11-12

Discarding the 9th bit leaves 0111 0100. Both operands were negative (sign bit 1), but the result's sign bit is 0 — overflow again, this time with a carry produced. Decoding 0111 0100 gives 116, a positive number, when both inputs were negative — an unmistakable sign something went wrong. The true answer, -70 + -70 = -140, is past -128 and doesn't fit.

Compare this pair of examples with Lesson 11 Example 4 (-5 + -3), where a carry was also produced but the decoded answer (-8) was correct — proof that the carry itself never tells you whether overflow happened.

Example 3 — Opposite signs never overflow, even at the extremes

127 (the largest positive 8-bit two's-complement value) plus -128 (the smallest):

0111 1111   (+127)

• 1000 0000 (-128)

1111 1111   <- no 9th bit

Opposite-sign operands, so overflow is impossible regardless of how close to the boundary either one sits. Decoding 1111 1111 gives -1 — correct (127 + (-128) = -1), and comfortably inside range.

Example 4 — Subtraction overflowing: 100 - (-50)

Per Lesson 12, this is 100 + 50 once -50 is negated back to +50:

0110 0100   (+100)

• 0011 0010 (+50)

1001 0110   <- no 9th bit

Both transformed operands (100 and the negated 50) are positive, but the result's sign bit is 1 — overflow. Decoding gives -106, nothing like the true answer. 100 - (-50) = 150, past 127, doesn't fit. Overflow applies to subtraction exactly the way it applies to addition, once Lesson 12's a + (-b) rewrite has been done — no separate rule needed for subtraction.