RIPPLE-CARRY the carry walks bit by bit up the chain — simple, and slow at the top
Wire n full adders in a line, carry-out to carry-in, and you have a ripple-carry adder: the simplest way to add n-bit numbers. Its cost is in its name — the carry must ripple from the lowest bit all the way to the highest, one adder at a time, before the top bit is final. The worst case (adding 1 to 0111…1) sends a carry the full width. It is correct and tiny, but its delay grows with the word size — which is exactly the problem the parallel schemes (lookahead, Kogge-Stone) exist to beat.
THE TECHNIQUE chain full adders; the carry propagates low bit → high bit
The demo adds two 4-bit numbers bit by bit, the carry rippling up the chain: 11+6=17: live demo
HISTORY & CREDIT the ripple-carry adder
“Addition is instant.” — in the simplest adder the carry walks the whole width one bit at a time, so the delay grows with the word size. The carry is the bottleneck. cited
the chain · full adders, carry-out to carry-in, low to high. the cost · worst-case delay is O(n) — the carry crosses every bit (add 1 to 0111...1). the answer · carry-lookahead (377) and parallel prefix (379) break the chain.
Correct, tiny, and slow at the top — the carry has to walk the whole way. The bottleneck that faster adders route around. ripple-carry
RECOMMEND FOR I-13 the rippling carry, on the compiler
On the canonical compiler, the bit-by-bit chain adds 11+6=17 — the carry rippling up through the full adders:
$ i13 run c_ripplecarry.i13 # chained full adders, carry ripples
RUN OK · 250 step(s) · peak stack 8 · call depth 6
sum = 17 -- 11 + 6, the carry walking low bit -> high bit
Recommend: the ripple-carry is the carry as a walk — correct and minimal, but its delay grows with the width — and i13 adds 11+6=17 the honest slow way. Not a keeper (a correct adder is correctness; “slow” is a resource property, which the B40 rule excludes). The dart that states the problem the rest of the batch's speed tricks solve.