RISC-V Sees Support For New ISA Extensions In Linux 6.11

[phoronix]

Phoronix: RISC-V Sees Support For New ISA Extensions In Linux 6.11

Palmer Dabbelt on Saturday sent out the RISC-V architecture updates for the ongoing Linux 6.11 merge window...

https://www.phoronix.com/news/Linux-6.11-RISC-V

[alpha_one_x86]

RISC-V with Linux 6.11 also has a number of performance improvements and memory hot-plugging support. The RISC-V memory hot-plugging code also allows for memory hot un-plugging.

Without forgeting memory hot un-plugging...

[rmfx]

It started so clean, now it’s packed with many Z ext that look like they could be part of the main ext. why so ?

[brucehoult]

I think that the ommision of flags will haunt RISC-V, and that the end-result will be a 1-4% performance penalty (compared to ARM, which has flags).

From whence does this supposed performance penalty come?

On the contrary, RISC-V's "compare two registers and branch" single instructions give a significant performance boost on low end implementations, and doesn't hurt on the high end. It is x86 and Arm that do instruction fusion to try to get the same advantage. Flags only give an advantage in the quite rare case of a three-way (or more) branch based on the same value.

No clean-sheet ISA since 1990 designed for high performance has had flags/condition codes. It's a huge bottleneck.

Even in 1990, IBM recognised that having a single set of flags are a problem, and put eight sets into RS/6000 aka POWER aka PowerPC. Since then DEC Alpha, Intel Itanium, and RISC-V have all gone for no flags.

x86_64 and Aarch64 have flags and are post 1990, but they are not clean-sheet ISAs. x86_64, obviously. Similarly Aarch64 has had to share pipelines and registers with Aarch32 for the first dozen years -- only in 2023 Arm started to make pure 64 bit cores.

[brucehoult]

Compilers are prohibited from ordering a comparison operation much earlier than the point where result of the comparison is required.

Not so. Compilers can use `slt`, `sltu` to do the early comparison, and then a simple `beqz`, or `bnez` branch later. Any register can be used as the flag.

It's very difficult to do the comparison early when there is a single set of flags and almost every instruction sets them, as on x86. Arm lets you choose whether to set the flags or not, but this doubles the opcode space usage of all the instructions that permit that. IBM, as I mentioned, provided eight sets of flags and compare instructions and conditional branches explicitly choose which set of flags to use. (regular arithmetic uses a fixed set)

On high end implementations OoO and register renaming solve this anyway.

If a branch gets wrong prediction, then RISC-V has to discard more pipeline stages than what is needed with two separate instructions.

The only reason you'd have a wrong prediction is because you don't yet know the values of the two registers being compared because they're coming from a load or a long latency instruction such as divide. Moving a compare earlier isn't going to help that!!

It is much easier to design OoO CPUs without flags. It could have been a cost-cutting measure.

Yes, it's easier to design a fast CPU without flags. That's my point. Cost-cutting at Intel, designing their #1 future forever ISA? I don't think so. INtel has the money to do it whatever way they want.

Arm could have removed flags in Aarch64, if they wanted it to.
It is not true that Aarch64 has to "share pipelines" with Aarch32.
The probable implementaion in that, internally, Aarch32 gets translated to Aarch64.

How do you translate Aarch32 to Aarch64 if Aarch64 doesn't have the same flags as Aarch32? Especially if you want the same performance from Aarch32 -- as all Arm cores I'm aware of have, certainly A53, A55, A72 (I don't have any Arm-designed Arm cores never than that ... Apple-designed cores are of course Aarch64-only since A11 (iPhone 8).

The two fastest cores in single-thread performance are currently x86-64 and Apple ARMs. They BOTH use flags.
So, what you are claiming is very probably false.

Proves nothing as people with lots of money only started to design high performance RISC-V applications processor cores after the huge November 2021 ratification of hypervisor, vector, crypto and a bunch of of other things. High performance cores and chips take time, so check back in around 2026-2027. Those companies are employing people such as the architect of Apple's M1 not to mention Jim Keller who was responsible for both Zen at AMD and then the current 13th/14th gen P+E core design at Intel (and many others dating back decades). Keller: “My belief is in the next 5 to 10 years, RISC-V will take over all the data centers”