The Floating-Point Register File's Separate Physical File: Why FP and Integer Registers Don't Share Silicon

2026-07-04

On paper, a physical register file is just a pool of storage slots that renamed logical registers get mapped into. So why do virtually all high-performance x86 and ARM cores maintain a separate physical register file for floating-point and vector state, distinct from the integer PRF? The answer is a collision of width, port count, and wire physics.

Consider the numbers. A modern integer PRF on Intel Golden Cove holds ~280 entries, each 64 bits wide — roughly 18 Kbit of storage. The FP/vector PRF holds ~332 entries, but each entry is 512 bits wide (for AVX-512) — about 170 Kbit, nearly 10x larger. Now overlay port requirements: the integer file needs something like 12 read ports and 6 write ports to feed six ALU pipes and the AGUs. The FP file only needs about 5 read ports and 4 write ports because vector pipes are fewer.

Register file area scales as roughly entries × width × (read_ports + write_ports)². The squared port term is why merging them is catastrophic: a unified file would need 17 read + 10 write ports at 512 bits wide. That's not just bigger — it's un-routable. Wire delay would push the register-read stage past a single cycle, blowing the entire pipeline's timing budget.

Concrete example: AMD Zen 4 keeps them fully separate. The integer PRF is ~224 entries × 64 bits with wide port count; the FP PRF is ~192 entries × 512 bits with narrower ports. When you do VMOVQ xmm0, rax (integer-to-FP move), the value physically travels across a cross-domain bypass path with a 2–3 cycle latency penalty. That penalty is the tax you pay for having separate files — and it's cheap compared to the alternative.

Rule of thumb: register file area cost ≈ entries × width × ports². Double the ports, quadruple the area. This is why architects will happily add a whole second file with duplicated allocator and free-list logic rather than widen a single one.

The domain split also enables independent scaling: AVX-512 support was added to Intel cores by growing only the FP PRF width from 256 to 512 bits. The integer file stayed untouched. If they shared silicon, every AVX generation would require re-timing the integer pipeline — a nightmare no architect wants.

The cost shows up in your code as domain-crossing penalties: MOVD, PEXTRQ, VMOVQ, and the reverse. Profilers surface these as "bypass latency" or "cross-domain forwarding stalls." Mixing SSE integer ops with general-purpose integer ops on the same value is measurably slower than staying in one domain.

Key Takeaway: The FP register file lives on separate silicon because register file area scales with the square of port count, and merging a 512-bit-wide vector file with a heavily-ported integer file would be physically un-routable at gigahertz clocks.

All newsletters