Arithmetic, flags, and three meanings of overflow

For a b-bit wrapping addition, keep the low b bits of the mathematical sum. Unsigned values represent zero through two to the b minus one, so a carry beyond the destination signals that the unsigned sum did not fit. The stored low bits are still well defined by that instruction. Signed two’s-complement values instead range from minus two to the b minus one through two to the b minus one minus one. The same bits therefore answer two different range questions.

For ordinary x86 ADD, the carry flag reports unsigned carry and the overflow flag reports signed overflow. Adding two positive signed operands that produces a negative signed result sets overflow; adding operands of opposite signs cannot overflow a fixed-width signed addition. These are instruction-specific effects, not universal properties of every arithmetic instruction. For example, some instructions preserve a flag that another updates. Read the entry for the exact operation and width before reusing a condition code in assembly.

Use sign bits to diagnose signed overflow: if both input sign bits agree and the result sign bit differs, the mathematical signed sum is outside the representable range. A carry out of the most significant position is not a substitute. In eight bits, 127+1 has no unsigned carry but does have signed overflow. Conversely, 255+1 has unsigned carry while its signed interpretation, minus one plus one, is exactly zero. Some sums have both conditions, and many have neither.

RV32I integer ADD does not set an x86-style condition-code register and does not trap on integer overflow; the low XLEN bits are retained. Software can detect conditions with suitable comparisons when necessary. Separately, a source language can give signed overflow a different status. In standard C, ordinary signed integer overflow is undefined behavior, while unsigned arithmetic is reduced modulo the type’s range after applicable conversions. A compiler need not preserve an intuitive signed-wraparound test unless the chosen language mode or operation actually supplies that guarantee.

A checked counter, a modular hash, and a saturating image operation require different behavior at their limits. A checked operation rejects or reports an out-of-range answer; modular arithmetic wraps; saturating arithmetic clamps to an endpoint. Replacing one with another changes the program, even if ordinary test inputs never approach the boundary. For allocation sizes, validate the multiplication and addition before passing the size onward. A wrapped size can allocate less storage than the later loop assumes it has.

The binomial lab has exact probabilities controlled by p and n. Set p to zero or one and predict the zero variance; then move away from the boundary. Its arithmetic is mathematical probability arithmetic, not a fixed-width ALU. The useful connection is the need to test boundary cases, not a claim that probability bars display overflow flags. For actual flags, construct a table of representative input patterns and compare the documented instruction behavior with the arithmetic interpretation you intend.