Fixed-width ISAs like ARM64 and RISC-V have it easy: every instruction is 4 bytes, so the decoder knows exactly where instruction N+1 starts before it even looks at instruction N. x86 doesn't have that luxury. An x86 instruction can be anywhere from 1 to 15 bytes, and you can't tell how long it is without partially decoding it. This creates a nasty serial dependency: to decode instruction 2, you first need to know where instruction 1 ends.

The instruction length predecoder (sometimes called the length decoder or ILD) is a small piece of hardware that sits between the L1 instruction cache and the actual decoders. Its only job is to scan the raw byte stream and mark the boundaries between instructions — where each one starts and where it ends. It doesn't figure out what the instructions do; it just finds their edges so the real decoders can work in parallel.

On Intel CPUs, the predecoder processes a chunk of bytes fetched from L1I (typically 16 bytes on older cores, up to 32 on newer ones) and produces a bitmap of instruction start positions. It handles prefixes, ModR/M bytes, SIB bytes, displacement fields, and immediates — enough to compute length without semantic decoding.

The catch: the predecoder has strict throughput limits. On Skylake, it can predecode at most 6 instructions per cycle, or up to 16 bytes per cycle, whichever comes first. If your average instruction is 4 bytes, you'll be byte-limited (16÷4 = 4 instructions/cycle) rather than instruction-limited. And there are painful edge cases: instructions with length-changing prefixes (LCPs — like a 16-bit immediate with an operand-size prefix) can stall the predecoder for 6 extra cycles because the prefix changes how many bytes the immediate occupies, and the predecoder has to reset its scan.

Real-world example: code compiled with 16-bit immediates (like mov ax, 1234h) inside a hot loop can tank front-end throughput on Intel chips. This is why compilers avoid emitting them in performance-critical code — a single LCP stall in a tight loop can drop IPC from 4 to under 1. Also, this is one of the biggest reasons the µop cache exists: once code has been predecoded once, subsequent iterations skip this hardware entirely and read pre-parsed µops directly.

Rule of thumb: if your x86 code averages more than 4 bytes per instruction and you're missing the µop cache, you're front-end bandwidth-limited before you even reach the decoders. Every extra REX prefix, every long immediate, every LCP is a tax that fixed-width ISAs simply don't pay.