Advanced Performance Extensions (APX)

High-level overview of what&#x27;s changing here:<p>* A new REX-like prefix that extends the number of addressable GPRs to 32 from 16. This only supports instructions that have one-byte opcodes or the 0f prefix, so recent GPR instructions like ADCX or BLSR aren&#x27;t supported with this format, except.<p>* The EVEX prefix (used for AVX-512) is also extended to be usable for GPR instructions instead of just vector instructions. This allows three-address instructions to be defined.<p>* The EVEX prefix for GPR also has a dedicated bit for &quot;do you want to set flags as a result of this instruction.&quot;<p>* New instructions that push&#x2F;pop 2 GPRs at once<p>* New instructions that let you conditionally set flags (basically you can do OR&#x2F;AND in the hardware flags, this sounds useful for compilers).<p>* New instructions for predicated loads.<p>* New 64-bit absolute jump instruction<p>* Also, implementation of the predicated stuff in AVX-512, but for 256-bit vectors. With this note:<p>&gt; A “converged” version of Intel AVX10 with maximum vector lengths of 256 bits and 32-bit opmask registers will be supported across all Intel processors, while 512-bit vector registers and 64-bit opmasks will continue to be supported on some P-core processors.

Interesting. More registers and separate destination on instructions is about 40 years overdue, but better late than never.<p>I realized I’ve completely lost track of Intel’s architecture extensions reading this:<p>“They do not change the size and layout of the XSAVE area as they take up the space left behind by the deprecated Intel® MPX registers.”<p>Apparently MPX was Memory Protection Extensions and the design was so flawed, it was removed entirely soon after introduction.

Apparently the Intel&#x27;s marketing had forgotten that they already had a product called iAPX (standing for “Advanced Performance arCHitecture”) and it did not go exactly well :)

&gt; extends the number of addressable GPRs to 32 from 16<p>I have always been curious as to why the number of GPRs were limited for so long on X86 given that the instruction set is already variable length, and the CPU have typically a very large number of internal arch-register that could be cheaply addressed.<p>Having looked at the pain of developing a good register allocate in LLVM, and how critical memory access can me in hot&#x2F;tight loops i would have loved to have even more register something closer to 64 or 128, and let the cpu manage the spilling internally.

So .... when will it ship? No mention of physical products anywhere.<p>I wonder why this long delays are still necessary. In the old days yes as there were so many parties to coordinate but nowadays, in theory, Intel could release hardware, the new ISA and compiler&#x2F;OS patches and binaries on the same day.

&gt; Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32.

&gt; &quot;legacy integer instructions now can also use EVEX to encode a dedicated destination register operand – turning them into three-operand instructions&quot;<p>x86 ISA is growing more RISC-like. Definitely saving on stack spilling is a Good Thing™

I thought it was going to be related to the iAPX (Intel Advanced Performance Architecture)<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IAPX" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IAPX</a>

So it sounds like (among other things) they&#x27;re adding 3-address integer instructions to an instruction encoding only used for vector instructions today.<p>I was not familiar with the AVX vector instructions at this level of detail.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;EVEX_prefix" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;EVEX_prefix</a>

The &quot;wall of text&quot; TL;DR:<p>- +16 registers (thus 32) and optionally separate destination (looking very RISC like now)<p>- PUSH2&#x2F;POP2 <i>with full forwarding</i><p>- Much expanded predication, including predicated loads and stores<p>This is pretty interesting. Especially the latter can make a big difference for highly unpredictable memory intensive code, like compression.

It is clear this is at least 2 - 3 years in the making. It doesn&#x27;t seems any of the 2024 products on Intel Roadmap will have APX ( This could be wrong ). So I assume the earliest being 2025.<p>The question is when will AMD adopt it. Zen 5 is done and Zen 6 may be too late for these changes. Zen 6 is already looking at 2026. If they waited til Zen 7 it will be at least 2028.<p>Intel is still 35% behind Apple in terms of Pref &#x2F; Clock on Geekbench.

&gt; Intel® APX demonstrates the advantage of the variable-length instruction encodings of x86 – new features enhancing the entire instruction set can be defined with only incremental changes to the instruction-decode hardware. This flexibility has allowed Intel® architecture to adapt and flourish over four decades of rapid advances in computing – and it enables the innovations that will keep it thriving into the future.

&quot;Intel® APX demonstrates the advantage of the variable-length instruction encodings of x86 – new features enhancing the entire instruction set can be defined with only incremental changes to the instruction-decode hardware.&quot;<p>In other words, their initial sloppiness was a Feature™: our initial mess was so bad that changes like these don&#x27;t make it any worse!

I don&#x27;t know much about CPUs, but isn&#x27;t this going to increase decoder complexity and binary size? The reduction in memory accesses seems great, but can anybody tell me if there are better ways of achieving this? x86 gets more complex each day.

So, in about 30 years when the majority of the CPUs have this, we can use it. Assuming intel does not gate this just to XEON for no reason whatsoever, like they did to AVX512?

Do this basically copies ARM’s Aarch64, but with a really awkward instruction encoding? Interesting move, Intel.

couldn&#x27;t find the info anywhere, but any ETA on this ? Or least what is the first Arch supporting this? Redwood Cove or someting later ?

Wow, perfect timing

It seems like most of these new instructions and registers correspond to the original armv8 base isa. I&#x27;m going to go out on a limb here and suppose that&#x27;s not an accident. Does anyone know why Intel thinks x86 needs them?<p>Is the goal here to increase the decode bandwidth of Intel CPUs?<p>Is the goal to reduce demands on load-store units by increasing the number of registers?<p>Are they hoping to make it easier to port or JIT armv8 asm to Intel CPUs?