The Magic Of ARM w/ Casey Muratori

ARM and x86/x64 aren’t fundamentally different “instruction sets for power” so much as they differ in how their machine code is encoded and decoded—and that decoding difference can matter for chip design. The most concrete hardware-level contrast comes from instruction encoding: x86/x64 uses variable-length instructions, while ARM (especially ARM64) uses fixed-size instruction encodings (with some ARM variants like Thumb introducing 16-bit forms). Variable-length encoding forces CPUs to do more complex decoding work to figure out where the next instruction begins, which complicates scaling to wider, multi-instruction-per-cycle decoders.

To make the comparison tangible, the discussion uses Compiler Explorer (godbolt.org), a tool that compiles the same C code and shows the resulting assembly and even the exact machine-code bytes. With a trivial function that just returns a value, the assembly looks nearly identical across architectures—differences mostly come from ABI conventions for where parameters and return values live. For example, on x86-64 System V ABI (as assumed by the setup), the first input parameter is placed in EDI and the return value comes back in EAX, so returning the first parameter may require a move. On ARM64, the first parameter and the return value can share the same register (R0/W0), so the compiler can avoid that move in simple cases; when returning a different parameter, ARM must move values into the return register too. The takeaway: the “ARM is better for low power” claim can’t be justified by instruction semantics alone, because the ISA-level differences don’t obviously show up in these tiny examples.

The hardware-level difference appears when looking at the actual bytes. x86/x64 instructions can be compact (e.g., a one-byte return) or longer (e.g., multi-byte encodings for other operations), so instruction boundaries aren’t known until decoding. ARM’s encodings are more regular: instructions are typically a consistent size, making it easier for the CPU to decode multiple instructions in parallel by fixed offsets. The practical implication is that x86 decoders often rely on “guessing” instruction boundaries and then falling back when guesses fail, while ARM can feed a straightforward fixed-offset decoding pipeline. That extra decoding complexity translates into real engineering cost—more circuitry, more power, and more difficulty sustaining high decode throughput.

Still, the conversation pushes back on attributing ARM’s historical low-power advantage purely to ISA design. Modern ARM chips (including Snapdragon and Apple M-series) execute complex instruction sets via micro-ops, similar to x86; the idea that ARM is “reduced” in the meaningful sense doesn’t hold up. Instead, the stronger explanation is market and ecosystem inertia: ARM grew up in low-power niches, with many licensees optimizing for battery life and thermal limits, while x86/x64 grew up in higher-power performance markets. Even when x86/x64 later pivoted toward efficiency, hardware design can’t change overnight. The openness of ARM licensing is also framed as a structural advantage—more designers can build ARM-based low-power systems, increasing the volume of innovation in that direction.

In the end, the most defensible “why ARM can be lower power” story is narrower: fixed-length decoding can simplify and reduce the cost of scaling instruction decode, which may help at the margins. But the biggest historical gap is portrayed as business dynamics and design lineage rather than a single magic ISA feature.