XOR'ing a Register with Itself Is the Idiom for Zeroing It Out. Why Not Sub?

Why It Matters

The choice of zero‑ing instruction directly impacts code size, execution throughput, and dependency chains, making xor the de‑facto standard for performance‑critical software.

Key Takeaways

• xor r,r uses one byte fewer than mov r,0
• sub r,r clears all flags, including AF, unlike xor
• CPUs detect xor r,r and sub r,r as zero‑register writes
• Zero‑detection breaks dependency chains, improving out‑of‑order execution
• Compiler conventions cement xor as the de‑facto standard

Pulse Analysis

In low‑level software development, every byte and cycle counts. Zeroing a register is a routine operation, but the instruction chosen can affect both binary size and pipeline efficiency. The xor r,r pattern encodes in a single byte, whereas mov r,0 requires a four‑byte immediate, shaving precious space from performance‑critical loops and embedded firmware. Compilers quickly adopted xor because it offered a clear advantage without sacrificing correctness, setting a precedent that rippled through the ecosystem.

Beyond size, modern CPUs employ special‑case detection for xor r,r and its sibling sub r,r. When the decoder recognizes a register being XORed or subtracted with itself, it substitutes the operation with an internal zero‑register write, effectively removing the instruction from the execution pipeline. This micro‑architectural shortcut eliminates latency, clears flags predictably, and—crucially—breaks true data dependencies, allowing out‑of‑order engines to schedule subsequent instructions earlier. While sub r,r also benefits from zero‑detection, its flag behavior (clearing AF) differs, and historical compiler bias has favored xor.

The legacy of xor as the zero‑idiom shapes today’s toolchains and hardware design. Compiler writers embed xor r,r as the default zeroing sequence, reinforcing the pattern across languages and platforms. CPU vendors, aware of this convention, prioritize detection for xor to guarantee consistent performance across architectures. For developers, understanding this nuance informs decisions when writing hand‑optimized assembly or tuning critical paths, ensuring they align with the underlying hardware’s expectations and maintain cross‑compiler portability.