8 ms·
Advanced Performance Extensions (APX)
- serhack_ 3y ago> Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32.
- _chris_ 3y agoAnd adds non-destructive instructions. > "In addition, legacy integer instructions now can also use EVEX to encode a dedicated destination register operand – turning them into three-operand instructions and reducing the need for extra register move instructions." Overall, APX is providing 10% fewer instructions, 10% fewer loads and more than 20% fewer stores. Also adding pop2/push2 instructions for moving state faster. And adding more powerful conditional instructions (loads/stores/compares) and flag-suppression.
- jeffbee 3y ago10% fewer instructions but average instruction is longer, so code density is the same, they claim. This still leaves their ISA with the worst code density of any non-obsolete ISA.
- Findecanor 3y agoI've only read one study [1] and its follow-up [2] with code-density benchmarks but according to them (one source), x86-64 is actually one of the denser contemporary ISA's ... provided that the compiler/programmer is smart enough to adapt to the ISA's quirks. 1. <https://www.researchgate.net/publication/224114307_Code_density_concerns_for_new_architectures https://www.researchgate.net/publication/224114307_Code_dens...> 2. <https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...>
- FullyFunctional 3y agoOh missed your comment and posted essentially the same. These are all interesting changes, predication certainly, but the thing that actually got me the most excited was the press release comment about: "The processor tracks these new instructions internally and fast-forwards register data between matching PUSH2 and POP2 instructions without going through memory." I wonder if this implies that pushes don't have to commit to memory if they are popped soon enough? It has always bothered me that we have these huge physical register files but force all the spill and restore to go through memory because of silly anachronistic processor semantics. With a more flexible PUSH/POP semantics we could essentially get the register windows for free.
- chc4 3y agoIntel x86 stack engines have done 0-cycle store/load forwarding for years now.
- FullyFunctional 3y ago? That was not my question nor my point. They hit memory and, as I have since learned, they still do after this. The wording in the press release was ambiguous. In other words, the news here is just being able to push/pop two in one µop.
- FullyFunctional 3y ago> "legacy integer instructions now can also use EVEX to encode a dedicated destination register operand – turning them into three-operand instructions" x86 ISA is growing more RISC-like. Definitely saving on stack spilling is a Good Thing™
- dfox 3y agoApparently the Intel's marketing had forgotten that they already had a product called iAPX (standing for “Advanced Performance arCHitecture”) and it did not go exactly well :)
- JohnFen 3y agoI genuinely thought that's what the article was about when I read the title.
- kjs3 3y agoYou mean the 8086, 80186, 80286 and 80386 and associated support chips?[1] Perhaps you and I have different definitions of 'go well'.[2] [1] https://en.wikipedia.org/wiki/IAPX https://en.wikipedia.org/wiki/IAPX [2] I know you're thinking about the iAPX432 and forgot the rest
- dmitrygr 3y agoSo, 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?
- brucethemoose2 3y ago"Tiered" x86 packages and executables seem like the inevitable direction for linux distros. CachyOS and Clear Linux already do this. Base Arch Linux and openSUSE are working on it. Maybe Fedora too, but I can't remeber And it wouldn't be totally insane for Windows to do this either.
- fooyc 3y agoHow does that work? The binary format embeds variants of the same program?
- brucethemoose2 3y agoOn linux distros, the package manager downloads different binaries based on your CPU. Skylake would be x86-64-v3, Zen 4 would be x86-64-v4, for example. And there are different schemes for multiple architectures in the same program, like hwcaps.
- kergonath 3y agoIsn’t this going to get very unmanageable very soon? Intel seems to add extensions every other year or so.
- jiggawatts 3y agoIt’s easy to fully automate and storage is relatively cheap these days.
- xxpor 3y ago
- brucethemoose2 3y ago> 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.
- KerrAvon 3y agoSo it sounds like (among other things) they're adding 3-address integer instructions to an instruction encoding only used for vector instructions today. I was not familiar with the AVX vector instructions at this level of detail. https://en.wikipedia.org/wiki/EVEX_prefix https://en.wikipedia.org/wiki/EVEX_prefix
- peterfirefly 3y agoHave you noticed that some of the bits in the EVEX prefix (after the 62h) byte are inverted? That's because it hides inside the BOUND instruction in a way that allows it to be used outside of 64-bit mode code. The BOUND instruction never existed in 64-bit mode, so Intel was free to do whatever they wanted with the 62h opcode, but they thought it would be enable EVEX in 16/32-bit code too. The BOUND instruction must take a memory operand -- so the MOD bits can never be 11b (which would specify a register operand). The MOD bits are the upper two bits of the modrm byte (the byte right after the 62h opcode). So, if we don't allow the "upper" registers in 32-bit mode and only the "lower" 8 registers AND if we invert bit 3 of their register numbers and put those extra register specifier bits in bit 7/6/5 of the byte after the 62h opcode THEN we can fit EVEX into 32-bit mode, because those bits will always be 111b in 32-bit mode! So outside of 64-bit mode, if we have a 62h opcode with a modrm byte with MOD!=11b: it's a BOUND instruction. If MOD=11b: it's an EVEX prefix.
- pavlov 3y agoInteresting. More registers and separate destination on instructions is about 40 years overdue, but better late than never. I realized I’ve completely lost track of Intel’s architecture extensions reading this: “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.” Apparently MPX was Memory Protection Extensions and the design was so flawed, it was removed entirely soon after introduction.
- deleted 3y ago[deleted]
- theandrewbailey 3y ago> More registers is about 40 years overdue, but better late than never. SSE, AMD64, AVX, and AVX-512 say hi.
- kjs3 3y agoAnd MMX from 1997...so almost 35 of those 40 years ago.
- jlokier 3y agoMMX didn't add new registers. It uses the same FP registers as those present all the way back to the Intel 8087 in 1980. You could say the MMX registers are older than the 32-bit x86 architecture, and therefore older than EAX, EBX, ESP etc.
- kjs3 3y agoNot exactly, especially in the context of this issue. You could use the MMX registers as 'traditional' registers (or at least a scratchpad), not quite like the x87 stack. There are 8 64-bit MMX registers. To avoid having to add new registers, they were made to overlap with the FPU stack register. This means that the MMX instructions and the FPU instructions cannot be used simultaneously. MMX registers are addressed directly, and do not need to be accessed by pushing and popping in the same way as the FPU registers. [1] [1] https://en.wikibooks.org/wiki/X86_Assembly/MMX https://en.wikibooks.org/wiki/X86_Assembly/MMX
- FullyFunctional 3y agoThe "wall of text" TL;DR: - +16 registers (thus 32) and optionally separate destination (looking very RISC like now) - PUSH2/POP2 with full forwarding - Much expanded predication, including predicated loads and stores This is pretty interesting. Especially the latter can make a big difference for highly unpredictable memory intensive code, like compression.
- _old_dude_ 3y agoAlso AVX-10, E-cores and P-cores having 512 bits vector registers (see the last references).
- jcranmer 3y agoIf I read the note correctly, P-cores won't have 512-bit vector registers, but they will have the other fancy stuff added by AVX-512 (namely, vector predication stuff, static rounding mode instructions, new vector instructions like complex multiply or half-precision float, and 32 vector registers), just only for 128-bit and 256-bit vectors. Which, to be fair, is arguably the more useful parts of AVX-512 anyways; the maximum vector length being upped isn't all that interesting.
- coder543 3y ago> If I read the note correctly, P-cores won't have 512-bit vector registers I don’t entirely agree. See the second graphic here: https://www.phoronix.com/news/Intel-AVX10 https://www.phoronix.com/news/Intel-AVX10 Mentioned above the graphic: > Part of making AVX10 suitable for both P and E cores is that the converged version has a maximum vector length of 256-bits and found with the E cores while P cores will have optional 512-bit vector use. 512-bit support will be optional, so maybe every P-core won’t have it… maybe it’ll be restricted to higher end processors? But it sounds like some will have it, or it wouldn’t be an option at all.
- adgjlsfhk1 3y agopresumably it will be the server chips that are all p cores that have it. to me it seems like a dumb choice, but it is consistent with what Intel is doing now
- user20230724 3y agoWow, perfect timing
- mike_hearn 3y agoSo .... when will it ship? No mention of physical products anywhere. 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/OS patches and binaries on the same day.
- wmf 3y agoThey don't want it to leak so they at least need to announce it before engineering samples go out.
- TheCondor 3y agoThey floated a "white paper" a few months back about removing legacy instructions. https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html https://www.intel.com/content/www/us/en/developer/articles/t... Taking a little time with these sorts of things isn't bad. This will essentially be a new epic where AMD and Intel may end up being incompatible, at least for a while, there are tooling changes to make, OS support, all sorts of things. If they're serious about dropping 16bit and 32bit from the architecture, doing it during a change like this might make some sense. Do it wrong and they could Osborn themselves, but an Apple like migration strategy would be nice and I'd appreciate it.
- mschuster91 3y agoThey announce it in time so that llvm, gcc, MSVC, Java, .NET and the browser JS engine vendors can update their stacks to be ready when the silicon ships. After all why spend a shitload of money on developing a feature you'll want to market when there won't be any reason for customers to buy your new hardware?
- mike_hearn 3y agoIntel employee people who work on Java and LLVM at least, so they could release their own versions of those. I guess V8 wouldn't be hard to add. The main reason to do a coordinated release would be competitive advantage, I guess, plus to ensure that there are actually compilers that support their new instructions available right from the start. Intel already release their own Linux distro optimized for their chips because other vendors were targeting the lowest common denominator
- muricula 3y agoIt seems like most of these new instructions and registers correspond to the original armv8 base isa. I'm going to go out on a limb here and suppose that's not an accident. Does anyone know why Intel thinks x86 needs them? Is the goal here to increase the decode bandwidth of Intel CPUs? Is the goal to reduce demands on load-store units by increasing the number of registers? Are they hoping to make it easier to port or JIT armv8 asm to Intel CPUs?
- adrian_b 3y agoMost new instructions are not inspired by Armv8, they just implement the traditional 3-address format for 32 registers, which predates Armv8 by a few decades. Nevertheless, there are a few instructions inspired by Armv8, mainly PUSH2 and POP2, which correspond to the load register pair and store register pair of Aarch64.
- comex 3y agoThe new CCMP conditional-compare instruction is also equivalent to ARMv8’s instruction of the same name. If a condition passes, compare two registers; if not, set the condition bits to an arbitrary value. On ARM that instruction is a pain in the ass when reading disassemblies, because the on-fail condition bits are just specified as a number from 0 to 15; the disassembler doesn’t bother to label which bits are specified, let alone what conditions they correspond to. Unfortunately it seems like Intel is doing the same thing in their assembly syntax, at least if I’m reading the document correctly.
- adgjlsfhk1 3y agowell given the difficulty of making wider x86 decoders it does seem pretty reasonable to try reducing the number of load/stores needed
- Bulat_Ziganshin 3y agoyeah, exactly. instruction fusing can turn mov+op2 into 3-reg operation, or push+push into push2. but adding new instructions allows to increase the frontend throughput too.
- jcranmer 3y agoHigh-level overview of what's changing here: * 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't supported with this format, except. * 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. * The EVEX prefix for GPR also has a dedicated bit for "do you want to set flags as a result of this instruction." * New instructions that push/pop 2 GPRs at once * New instructions that let you conditionally set flags (basically you can do OR/AND in the hardware flags, this sounds useful for compilers). * New instructions for predicated loads. * New 64-bit absolute jump instruction * Also, implementation of the predicated stuff in AVX-512, but for 256-bit vectors. With this note: > 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.
- andromeduck 3y agoIt's CISC-V
- jamesy0ung 3y agoI thought it was going to be related to the iAPX (Intel Advanced Performance Architecture) https://en.wikipedia.org/wiki/IAPX https://en.wikipedia.org/wiki/IAPX
- soulbadguy 3y ago> extends the number of addressable GPRs to 32 from 16 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. Having looked at the pain of developing a good register allocate in LLVM, and how critical memory access can me in hot/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.
- jcranmer 3y ago> 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. Because it's hard-ish to wrench in the encoding bits. x86 registers are addressed via the ModR/M byte, which gives you 4 addressing modes × 2 register operands (if you have 8 registers). Note that non-register-register addressing modes include a second SIB byte which means you have up to three registers encoded in an instruction. x86-64 extended the number to 16 by adding a prefix that has 4 bits, which encoded a 32-bit/64-bit selector and 1 bit for each of the three possible registers (R, X, B). Note that to keep the prefix to only a 1-byte length, they had to reclaim 16 possible opcodes, whose space is pretty limited. Encoding large register numbers gets pretty chonky in instruction space (3 register ids of 5 bits each is 15 bits of your instruction for operands, and that's before you start considering possible opcodes). It also increases the size of context switches (especially thread contexts), since you have to spill all of those registers even if they're not filled with useful data. 8 registers is definitely too few; it's not clear to me if the extra working set size afforded by 32 registers is worth it over the fatter instructions.
- duped 3y agoThey're not really limited since the instruction decoder is actually doing a bunch of work to assign to physical registers. The 16 GPRs are an abstraction, iirc. Even though it's only one extra bit to index 16 registers vs 8, it takes an entire extra byte in the encoding (you have to add the REX prefix with the R, X, and B bits set appropriately for the MSB of the registers you're modifying in the MODR/M byte). And you only get 4 bits to use out of that byte because the leading four are a way to disambiguate it (also iirc, this stuff is terribly documented). And paying an extra byte per GRP instruction is actually kind of expensive. If you look at your compiler output you'll see a bunch of Exx instructions even in 64 bit long mode when optimizing for instruction decode/size. It turns out a variable length encoding is really hard to extend without getting weird with it.
- soulbadguy 3y agocouldn't find the info anywhere, but any ETA on this ? Or least what is the first Arch supporting this? Redwood Cove or someting later ?
- johnklos 3y ago"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." In other words, their initial sloppiness was a Feature™: our initial mess was so bad that changes like these don't make it any worse!
- ribit 3y agoDo this basically copies ARM’s Aarch64, but with a really awkward instruction encoding? Interesting move, Intel.
- voidbert 3y agoI don't know much about CPUs, but isn'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.
- vgatherps 3y agoThese changes reduce the amount of instructions you need in the first place - less stack shuffling with more registers and push2/pop2, less register shuffling with nondestructive operations
- ksec 3y agoIt is clear this is at least 2 - 3 years in the making. It doesn't seems any of the 2024 products on Intel Roadmap will have APX ( This could be wrong ). So I assume the earliest being 2025. 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. Intel is still 35% behind Apple in terms of Pref / Clock on Geekbench.