The radix 2^51 trick (2017)

> Aside: Why 13 bits instead of 12? For our purposes, we’re going to ignore the carries in the most significant limb, allowing numbers to wrap when they overflow past 2256 - 1 (just like how unsigned addition works in C with normal size integer types). As a result, we can assign 52 bits to the most significant limb and ignore the fact that it will run out of room for carries before the other limbs do.

Why not give the top limb 64 bits and the other four limbs 48 bits each, then? You can accumulate more additions before normalization, you can take advantage of word alignment during splitting and normalization if your instruction set has anything useful there, and your overflow properties are identical, no?

uops.info has latency for both (Alder Lake) at 1 cycle but throughput (lower is better)

* for add is 0.20 (ie 5 per cycle)

* for adc is 0.50 (ie 2 per cycle)

so it does seem correct.

This seems to be a consequence of `add` being available on ports 0, 1, 5, 6, & B, whereas `adc` is only available on ports 0 & 6

So yes as an individual instruction it’s no worse, but even non-dependent instructions will be worse for OoO execution (which is more realistic than viewing it as a single instruction)

Someone working entirely on x86_64 very nicely demonstrates that RISC-V is not wrong to omit the carry flag.

Does C++ have native support for uint256?

Yes, it complies with the as-if rule; there's no observable difference in behavior. This would apply as well for supporting 64 bit additions within a loop on 32- or 16-bit architectures, for example.