Last time I checked, x87 (and MMX which uses the same register file) aren't renamed. There's only the architectural register file. At that point these sorts of concerns don't matter because you're not metaprogramming rename hardware through the veneer of the architectural registers.
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.
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.
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.
If x87 and MMX registers don't support renaming then that means that they can't support OOO and speculative execution of these instructions. This is possible but seems unlikely to me.
That is, even though not a lot of x87/MMX code is executed these days (and even less is written) I would be surprised if the OOO/speculative-execution of the processor gets halted whenever these instructions are encountered.
Note that x87 instructions still get used in most 32-bit programs because the x87 registers are the defined way for functions to return floating-point results.
> That is, even though not a lot of x87/MMX code is executed these days (and even less is written) I would be surprised if the OOO/speculative-execution of the processor gets halted whenever these instructions are encountered.
The implications aren't that bad. Only instructions using the outputs of x87/MMX instructions would have to stall. And especially if you're only using them to shift values during function returns, then that wouldn't have to have a huge impact on performance.
It looks like my information was woefully out of date. They're fully renamed and executed OoO now, and on Intel even share a PRF with AVX-512 K registers interestingly enough.
