Whenever new registers are added to a CPU, it may be necessary to modify the operating system in order to save the new registers across context switches, but it is possible to change the ABI (i.e. the conventions for calling functions) in such a way that will allow the new functions that use the new registers to be linked with old functions that are not aware of the existence of the new registers.
To achieve this goal, it is enough to define in the ABI all the new registers as "caller-saved volatile".
This means that any function that uses some of the new registers must not assume anything about the values of those registers upon function entry and it must save them before calling any other function.
This ensures that regardless what other functions do, intentionally or accidentally, the values stored in the new registers cannot be corrupted, so it is safe to mix new functions that are aware of them with old functions that ignore them.
Had the new registers been defined e.g. as registers that must be preserved across calls, i.e. which must be saved inside the invoked function, that would not have worked, because an old function would not have known how to save them.
Not every function boundary is an ABI boundary, and compilers can and will automatically use custom ABIs for static functions (and, with LTO, for unexported global functions, too).
> As out-of-order CPUs continue to become deeper and wider, the cost of mispredictions increasingly dominates performance of such workloads. Branch predictor improvements can mitigate this to a limited extent only as data-dependent branches are fundamentally hard to predict.
> To address this growing performance issue, we significantly expand the conditional instruction set of x86, which was first introduced with the Intel® Pentium® Pro in the form of CMOV/SET instructions. These instructions are used quite extensively by today’s compilers, but they are too limited for broader use of if-conversion (a compiler optimization that replaces branches with conditional instructions).
> Intel® APX adds conditional forms of load, store, and compare/test instructions, and it also adds an option for the compiler to suppress the status flags writes of common instructions.
https://www.intel.com/content/www/us/en/developer/articles/t...
I didn't understand everything about the "caller-saved volatile" new general purpose register interface & legacy compatibility. But some potentially really interesting optimizations where load/store being dual register capable, and being capable of staying on the AVX unit & not having to go further out to "memory" (caches?):
> Generally, more register state will need to be managed at function boundaries. In order to reduce the associated overhead, we are adding PUSH2/POP2 instructions that transfer two register values within a single memory operation. The processor tracks these new instructions internally and fast-forwards register data between matching PUSH2 and POP2 instructions without going through memory.
Neat stuff. Very superficially reminds me of Semantic Streaming Registers on the very novel standalone-ish FPU on PULP's RISC-V based Occamy many-core chip. In that the unit is acting in a more standalone fashion. https://www.youtube.com/watch?v=kMhdq7A3d3I#t=10m https://pulp-platform.org/docs/BeniniSC11-22.pdf