Observing x86 register dependencies

Question

Are there any other processor registers (e.g. flags) besides the architectural registers (eax, ebx,.) in x86 for which RAW dependencies need to be enforced by the scoreboard in pipelined processors?

Answer 1

Literally every register guarantees that if you write it, later instructions will read the new value.

x86 is defined in terms of serial execution; pipelining and out-of-order exec need to preserve that illusion for everything, including segment registers, FP rounding modes, control and debug regs, and obviously FLAGS.

A CPU needs to either detect RAW (and other) hazards or make instructions that write that register serializing (drain the pipeline).

---

Yes, of course FLAGS is renamed, otherwise WAW / WAR hazards would cause a false dependency between almost every integer instruction, and of course RAW true dependencies have to be detected so instructions that read FLAGS can get the correct input despite out-of-order exec.

Modern x86 CPUs do register renaming (Tomasulo's algorithm), not just scoreboarding. Hopefully you mean using a scoreboard to detect those dependencies as part of register renaming? Loop optimization. How does register renaming break dependencies? What is execution port capacity?

Also of course FP / SIMD registers, including the x87 status word that contains the TOP field, because this is part of renaming x87 registers.

The only way to avoid doing renaming for a register is to make writes to it serialize execution so there can't be instructions in flight that still need to read or write the old value. e.g. on some microarchitectures segment registers aren't renamed, so mov Sreg, reg has to drain the ROB. Is a mov to a segmentation register slower than a mov to a general purpose register?

On some uarches, the MXCSR and/or x87 control word (containing rounding modes) isn't renamed. A random Intel document that google found documents perf counter sub-events for resource_stalls, which can include MXCSR rename stall cycles. IDK which uarch this is for:

MXCSR rename stall cycles

Stalls due to the MXCSR register rename occurring too close to a previous MXCSR rename. The MXCSR provides control and status for the MMX registers.

See also Agner Fog's microarch pdf which might mention some details like this.