GNU Assembler Starts Getting Ready For Intel AVX10.1

[phoronix]

Phoronix: GNU Assembler Starts Getting Ready For Intel AVX10.1

Back in July Intel announced AVX10 as the future of AVX-512 and how they ultimately plan to support more Advanced Vector Extensions capabilities on both future P and E cores. Since then they've begun making preparations to the open-source compiler toolchains around enabling AVX10...

https://www.phoronix.com/news/GNU-Assembler-AVX10.1

[stormcrow]

Since this is merely a re-branding of certain AVX512* features, there's little code to be added.

Well this cleared up a question I'd been silently asking since AVX10 was announced. It's not really new, just re-labeled to save face over the screw-ups with the AVX-512 P/E core fiasco (in front of investors, my guess, since any developers would know soon as they looked at an implementation manual it wasn't new).

[uid313]

AVX-whatever. I think AVX10.1 sounds rather uninteresting. More interesting is Intel Advanced Performance Extensions (APX).
But APX is a whole new backwards-incompatible ISA to be implemented side-by-side with x86? Then why not just implement RISC-V instead of APX?

[stormcrow]

AVX-whatever. I think AVX10.1 sounds rather uninteresting. More interesting is Intel Advanced Performance Extensions (APX).
But APX is a whole new backwards-incompatible ISA to be implemented side-by-side with x86? Then why not just implement RISC-V instead of APX?

Because RISC-V isn't compatible with x64 just like Itanium wasn't a viable alternative to people using x32 hardware. x32 emulation on Itanium was a joke and Itanium CPUs cost many times more than a x86 CPU. It's like we want you to turn your back on all that investment you made on x86, but then we're going to kick you in the ass for writing all that software code you trusted us enough to write. In comparison, x64 emulation on M-class Arm is pretty seamless and performant outside of corner cases to facilitate switch over while x32 emulation on Itanium was like trying to get a pig not to wallow in mud on a hot summer day. RISC-V would require proprietary/patent encumbered extensions to emulate x64 while it would take billions in investment and years of iteration to do it right. Just like what Apple did with M CPUs. So you actually win nothing going down that path other than perhaps in 15 years you might be able to drop those proprietary extensions. But don't hold your breath, because Intel doesn't have the vertical integration and fairly tame developer crowd that Apple can leverage ready to go along with all the transitions Apple makes. Intel has to deal with enterprises that would never update anything if they could manage to do so. The upgrades their primary customers plan are nearly always evolutionary, not revolutionary. Intel learned that lesson well over Itanium.

[uid313]

Because RISC-V isn't compatible with x64 just like Itanium wasn't a viable alternative to people using x32 hardware. x32 emulation on Itanium was a joke and Itanium CPUs cost many times more than a x86 CPU. It's like we want you to turn your back on all that investment you made on x86, but then we're going to kick you in the ass for writing all that software code you trusted us enough to write. In comparison, x64 emulation on M-class Arm is pretty seamless and performant outside of corner cases to facilitate switch over while x32 emulation on Itanium was like trying to get a pig not to wallow in mud on a hot summer day. RISC-V would require proprietary/patent encumbered extensions to emulate x64 while it would take billions in investment and years of iteration to do it right. Just like what Apple did with M CPUs. So you actually win nothing going down that path other than perhaps in 15 years you might be able to drop those proprietary extensions. But don't hold your breath, because Intel doesn't have the vertical integration and fairly tame developer crowd that Apple can leverage ready to go along with all the transitions Apple makes. Intel has to deal with enterprises that would never update anything if they could manage to do so. The upgrades their primary customers plan are nearly always evolutionary, not revolutionary. Intel learned that lesson well over Itanium.

You are a bit confusing. There is nothing called x32, what you mean is x86-32 or simply x86. There is no thing called x64, what you meant is x86-64.
Is Intel APX even backwards compatible with x86 and x86-64?
Isn't Intel APX a brand new ISA? Or is APX just some extensions?
Does Intel APX still need x86?
Is Intel APX a superset of x86, or a complete independent full ISA to run side-by-side as two different ISA on the same CPU core?

[Weasel]

You are a bit confusing. There is nothing called x32, what you mean is x86-32 or simply x86. There is no thing called x64, what you meant is x86-64.
Is Intel APX even backwards compatible with x86 and x86-64?
Isn't Intel APX a brand new ISA? Or is APX just some extensions?
Does Intel APX still need x86?
Is Intel APX a superset of x86, or a complete independent full ISA to run side-by-side as two different ISA on the same CPU core?

Superset, extension, backwards compatible. Adds a new prefix, so most of the instructions using the new features (registers) take more bytes to encode (more bloated).

Note that it is normal for wasting more bytes to encode more registers, simple logic. A 32 register file requires 5 bits to encode, and with 3 operands that's 15 bits already. A 8 register file (original 32-bit x86) only requires 3 bits per register, and having 2 operands, 6 bits.

You guys think addressing registers is free or what?

[mb_q]

Maintaining a program aiming to support full AVX power on a typical computer has become even more fun (;

[ayumu]

And Intel-exclusive. AMD (which makes the better x86 processors) hasn't declared any intention to implement this nor APX.

I'll just skip and go straight to RISC-V.