Sorry, I'm coming at this from a pretty low level. Things like ALUs sometimes use lookup tables to do things like N bit multiply, instead of carrying bits seria

Sorry, I'm coming at this from a pretty low level. Things like ALUs sometimes use lookup tables to do things like N bit multiply, instead of carrying bits serially like in a 1 bit handheld calculator. But there are fundamental limits to that where maybe there just isn't transistor budget to multiply more than 8 or 16 bits or something. Or there are propagation delay issues where the circuit just can't get any faster, so instructions must be pipelined to approach something like 1 instruction per cycle. So it really depends on the architecture. Sometimes it makes sense to have "native" 64 bit math, and sometimes it makes sense to compose a 64 bit operation from many 8/16/32 bit operations. In this case, I would opt for using as few transistors as possible per-core in order to fit more cores on the chip. Then expose a 64 bit architecture, but implement that as 8/16/32 bit software loops in the microcode. So maybe a multiply might take 2 or 4 or 8 cycles or something instead of 1. In practice superscalar architecture, pipelining, caching, even hyper-threading, can hide much of that because processors today usually run dozens or even hundreds of times faster than main memory. So I highly doubt that chips today actually implement every single 64 bit instruction in hardware. Granted, my knowledge around this is over 20 years old, but it comes from studying stuff like MIPS processors, so is about as fundamental as it gets. And single-threaded performance has only roughly tripled since the 90s. My guess is that they use more lookup tables now since transistors are basically free. At the cost of never going back and checking how effectively they're using their transistor budget for actual computation, which results in the CPUs we have today that run many thousands of times slower than they could. We see this in how GPUs absolutely dwarf the performance of CPUs.