Welcome x86, seriously...

[brucehoult]

https://godbolt.org/z/h9T8cE7jn

https://godbolt.org/z/jKjhc93jM

Thanks to dzaima for the examples.

[Nominal Animal]

What am I missing?  Are you referring to Intel APX finally adding a destination register (three-operand form), similar to how the destination register on e.g. RISC-V and ARMv7/Thumb is specified separately from the source registers?

[brucehoult]

What am I missing?  Are you referring to Intel APX finally adding a destination register (three-operand form), similar to how the destination register on e.g. RISC-V and ARMv7/Thumb is specified separately from the source registers?

Yup, 32 GPRs and 3-address instructions, just like MIPS, SPARC, PA-RISC in 1985-1986, and i960, AMD 29000, M88000, RS/6000 2 or 3 years later, and Alpha a couple of years years after that.

Arm got there in 2015 (shipping products), and now x86 40 years after the crowd, assuming they ship hardware in 2025.

[coppice]

I believe some of the people who developed the Am29000 went on to develop the x86_64 instruction set, yet didn't add those three address instructions.

[Nominal Animal]

I already consider the x86/AMD64 instruction set "hopeless", especially compared to RISC-V or even ARM/AARCH64.  Just consider having to implement an instruction decoder to detect and simulate loads from unmapped/no-access-mapped virtual memory pages.  I get the heebie-jeebies just thinking about it.

[ejeffrey]

I believe some of the people who developed the Am29000 went on to develop the x86_64 instruction set, yet didn't add those three address instructions.

I remember them explaining that they considered it, but the encoding changes were easier to go to only 16 GPRs and stick with two operand instructions.  Remember Intel was pushing Itanium at the time and AMD was trying to avoid being left behind.  Any more radical departure would have been a bigger risk.

[brucehoult]

I believe some of the people who developed the Am29000 went on to develop the x86_64 instruction set, yet didn't add those three address instructions.

According to Intel's press release when they announced APX back in July 2023 "APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline. Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations." So that's the effect of having more registers.

Also: "there are 10% fewer instructions in APX-compiled code2". Loads and stores typically make up maybe 30% of instructions,  so the reduction in loads and stores might account for half of that. The rest will be from eliminating MOV instructions via using 3-address instructions.

There are also a number of other additions:

- 3-address instructions always zero-extend 8 and 16 bit results to the full register, not merge with the old destination upper bits

- option to not set flags

- PUSH and POP on two registers at a time

- new conditional instructions CCMP and CTEST to simplify control flow

[SiliconWizard]

I believe some of the people who developed the Am29000 went on to develop the x86_64 instruction set, yet didn't add those three address instructions.

I remember them explaining that they considered it, but the encoding changes were easier to go to only 16 GPRs and stick with two operand instructions.  Remember Intel was pushing Itanium at the time and AMD was trying to avoid being left behind.  Any more radical departure would have been a bigger risk.

Yes, that pretty much what it was. And history has taught Intel that anything a bit too radical would not work for them.

The sad part of it all is that users of x86(-64) CPUs, for most, do NOT want any radical change. They'll cry at the smallest attempt. So, everybody whines about how the x86 architecture sucks, and at the same time, no one wants it to change. So what is Intel to do? Just milk the cow until the market is definitively gone. What else?

Now, Intel CPUs, even with this funky instruction set (that has become an absolute monster) still is king in terms of performance, compared to anything ARM or RISC-V. That may change, but it won't overnight.
Also, that monstrous instruction set helps them not getting cloned too easily. AMD is the only serious competitor. I know there's a chinese x86, but it's way behind in terms of performance.

I don't know what their long-term strategy is. Are they planning on releasing RISC-V CPUs with comparable performance and the idea that they'll replace x86 over time? Possibly. Will people buy anything other than x86 from Intel? I frankly have no clue, but I know this is gonna be a rough ride for them.

[brucehoult]

Now, Intel CPUs, even with this funky instruction set (that has become an absolute monster) still is king in terms of performance, compared to anything ARM or RISC-V. That may change, but it won't overnight.

Absolute performance, yes, though Apple's implementation of the Arm ISA is neck and neck with them.

For RISC-V, we're just now this month five years after the initial RV64GC+priv stuff was frozen and ratified, and 2 1/2 years since a large lump of stuff essential for phones, desktops, servers was added (Vector, Hypervisor, cache management operations, ...). Things which the Android people say are essential are in RVA23 which isn't ratified yet (or maybe was at the Summit last week ... I'm not sure).

It takes a good five years to design a modern high performance core and get it to market. Several different companies employing people of the caliber of Jim Keller and Wei-han Lien (chief architect of the M1 at Apple) started working on RISC-V designs in 2022 or so, with serious financing behind them. There is every reason to think they can do again what they've done before (many times, in the case of Keller). Most recently, I believe Keller was behind Intel's recent (very successful) move to P cores and E cores. [1]

So, no, RISC-V won't be competitive with x86 at the high end overnight, but the designs are well into the pipeline and will be in a store near you in maybe 2027. Certainly well before the end of the decade.

We're getting early Core i7 performance (maybe around Sandy/Ivy Bridge) around the end of this year with the 16 core SG2380 -- so actually more of a Xeon or i9 except i9 wasn't until Skylake and Sandy/Ivy Bridge Xeon topped out at 6 or 8 cores per chip. And it's not going to turbo as high ... more like the base speed of a Xeon with a lot of cores.

[1] I just love my 24 core i9-13900K Lenovo laptop: 8 P cores and 16 E cores. By the time you're maxing out the 8 P cores the clock speed has already dropped from 5.3 GHz to 4.1 GHz, so the fact that the E cores *can't* run over 4 GHz loses you nothing.

[DiTBho]

Absolute performance, yes, though Apple's implementation of the Arm ISA is neck and neck with them.

Well, speaking of Apple ...
... they made their own A.I. niche, namely "Apple Intelligence", on both sw and infrastructure side, and put specific hw only in the chips starting from Apple Silicon M4.

On a technical level there is no neural network that can satisfy *all algorithms* and *all artificial intelligence models*, so there is no way to design a generic NPU, in fact if we look at Google Corla and Hailo, they are not at all identical and accelerate different things. However, Apple has tried to develop non-homogeneous NPUs, helping them with different cores and different solutions to make all the units communicate in the most efficient way possible.

So not just ISA

But now there are - legal? ethical? related to consumer rights? - problems with Europe.

I find this matter much more interesting than the things Intel and AMD do to keep their x86 alive.

[DiTBho]

monstrous instruction set

Think that one of those who has always pointed out that x86 is ISA crap, in 2024 is proposing in university courses to work on the 8088 assembly (  )  for exams in which IJVM should be used...

... if the world hasn't gone mad ... then it's really true that with money you can change anyone's opinion, even engineers who are offered double, triple, quadruple their salary, to work on what they personally think is crap, rather than on RISC_V or whatever they personally feel should be better invested effort.

[DiTBho]

in maybe 2027. Certainly well before the end of the decade.

That is, for when(x) man returns to the Moon,
      2027 =< when(x) =< 2030
We are building the "moon gateway" module by module.
We probably won't use RISC_V in any of those missions.