For SIMD-based FP, you can use VZEROUPPER and VZEROALL if you want to clear all {X,Y,Z}MM state. For a single register, I believe PXOR is still the common idiom, mirroring `XOR EAX, EAX`.
Should read: for x87, unless you are doing this for fun, shoot yourself in the face and instead use SSE because no one in their right mind should be writing x87 code in 2021!
Please help this architectural misfeature die, which should have happened decades ago.
My information is pretty old, but IIRC x87 still has specialized instructions for sin/cos/tan that are sometimes more performant than their equivalent implementations in SSE. x87 instructions are also very small, so trig-heavy workloads where I$ is a measurable performance component might unfortunately still be a good fit for x87.
For future CPUs, it is expected that the performance gap will increase.
The x87 trigonometric functions require typically between 100 and 200 clock cycles. During that time a recent CPU can execute 200 to 500 instructions, enough to compute many values of a trigonometric function (using a polynomial approximation). When SIMD instructions can be used, several tens of values of a function could be computed during a single x87 instruction.
If a trigonometric function is encoded as a single instruction, then it must launch a microprogram, to execute the many required steps.
A microprogram cannot execute faster than when the same execution steps would have been encoded as separate instructions, the only advantage of encoding a trigonometric function in a single instruction would be to reduce the program size. Most programs contain few trigonometric functions, so the reduction in program size is not worthwhile.
While a microprogrammed trigonometric function could be as fast as the equivalent sequence of instructions, in reality it is usually much slower.
The reason is that the modern CPUs are optimized for the most frequent instructions and they dedicate a minimum of resources for the seldom used microprogrammed instructions, so these hit various limitations that do not exist for the simple instructions. The microprogrammed instructions usually have some phases whose execution cannot be overlapped in time with other instructions, which leads to lower performance.
They absolutely are not. If you accept the same, crappy precision, you can do an estimate in just a few cycles instead of the 60+ that the instructions take.
If anything, AMD improved its handling on recent Zens.
Take a look at Agner manuals.
It is plausible it will be dropped at some point but we are not there yet.
[1] newer atoms, although a
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.
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.
> 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.
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.
Which is to say, citation needed.
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.
Thanks for keeping me honest.