2 ms·

I guess I didn't really consider the manual renaming via fxch the same kind of renaming, and that equally doesn't apply to these sorts of zeroing concerns. Tha

I guess I didn't really consider the manual renaming via fxch the same kind of renaming, and that equally doesn't apply to these sorts of zeroing concerns. That being said, it looks like my information is a little out of date, and they are renamed fully now and share a PRF with the AVX-512 K registers.

gpderetta 5y ago
FXCH has always existed; before PPro, FXCH was a normal FP instruction that was needed to manipulate the physical architectural register stack (as most x87 instructions implicitly operated on the top of stack). Since PPro there isn't really a register stack anymore. FXCH is not a "real" instruction any more, it has 0 latency and uses no execution resources, and it is resolved at the renaming stage and aliases the implicit stack positions to actual fp registers.
- monocasa 5y ago
  According to agner, FXCH didn't actually move values around on Pentium and Pentium MMX processors either despite them being in order cores. There was 'rename hardware' sitting in front of the x87/MMX register file, but there wasn't this distinction of size between architectural and physical register files. Despite renaming, there was still only one physical register for each architectural register at a time (except for a cute bypass technique combined with FXCH). > The solution to this problem is register renaming. The FXCH instruction does not in reality swap the contents of two registers; it only swaps their names. Instructions that push or pop the register stack also work by renaming. Floating point register renaming has been highly optimized on the Pentiums so that a register may be renamed while in use. Register renaming never causes stalls - it is even possible to rename a register more than once in the same clock cycle, as for example when FLD or FCOMPP is paired with FXCH. So, like I stated originally, the presence of FXCH and x87 stack doesn't necessarily imply the the same sorts of physical register allocation dependency breaking concerns involved with "how do I zero a register properly". They do now though, as it looks like there's true renaming going on now.

gpderetta 5y ago

FXCH has always existed; before PPro, FXCH was a normal FP instruction that was needed to manipulate the physical architectural register stack (as most x87 instructions implicitly operated on the top of stack). Since PPro there isn't really a register stack anymore. FXCH is not a "real" instruction any more, it has 0 latency and uses no execution resources, and it is resolved at the renaming stage and aliases the implicit stack positions to actual fp registers.

monocasa 5y ago
According to agner, FXCH didn't actually move values around on Pentium and Pentium MMX processors either despite them being in order cores. There was 'rename hardware' sitting in front of the x87/MMX register file, but there wasn't this distinction of size between architectural and physical register files. Despite renaming, there was still only one physical register for each architectural register at a time (except for a cute bypass technique combined with FXCH). > The solution to this problem is register renaming. The FXCH instruction does not in reality swap the contents of two registers; it only swaps their names. Instructions that push or pop the register stack also work by renaming. Floating point register renaming has been highly optimized on the Pentiums so that a register may be renamed while in use. Register renaming never causes stalls - it is even possible to rename a register more than once in the same clock cycle, as for example when FLD or FCOMPP is paired with FXCH. So, like I stated originally, the presence of FXCH and x87 stack doesn't necessarily imply the the same sorts of physical register allocation dependency breaking concerns involved with "how do I zero a register properly". They do now though, as it looks like there's true renaming going on now.