[leucineleprec0n]

Instruction set baselines should ideally be well-regulated open standards. They should also be good, and not moronic academic projects running of 32B opcode space because of religious dedication to silly extensions and the uniformity of an ISA for saving pennies on microcontrollers to high performance CPUs.

RISC-V in principle is a great idea. Hopefully we’ll get something that’s at the caliber of a well-oiled machine backed by real experience and practical high performance use like Arm V8 and V9 someday that’s a bit more open, but as of right now RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation.

https://www.theregister.com/2024/05/29/riscv_messsaging_stru...

And here’s David Chisnall on ISAs, which do matter:

https://queue.acm.org/detail.cfm?id=3639445

[Vt71fcAqt7]

I don't see why "moronic" was needed there. Also Risc-V has profiles that group multiple extensions together for specific use cases. For example RVA23[0] which requires 64 bit and vector extension among many others. Operating systems like android can (and most likely will) specify that they only support certain profiles.[1] Lastly, ARM is also fragmented between Armv8 and Armv7 which android developers are still supporting.

>RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation.

Do you have any evidence to support this? Seems like RVA23 will be the first majorly supported extension. All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.

[0] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...

[1] https://opensource.googleblog.com/2023/10/android-and-risc-v... (note: the blog mentions RVA22 but this has most likely been switched to RVA23 before full Risc-V support lands in Android).

[snvzz]

>All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.

It comes straight from the "RISC-V know the facts" FUD campaign ARM infamously ran.

Yet, not even these dev kits suffer from "fragmentation". Basically:

- Previous wave implements RVA20, some of them with custom extensions, such as a harmless pre-ratification V extension.

- The open software ecosystem is built for RVA20, which the hardware supports. Vendors run their experiments within custom extension space, no harm is done.

- Current wave implements RVA22 with the ratified V extension, some of them with harmless custom extensions. As newer RVA profiles build on older RVA profiles, these chips run RVA20 code no worse than the previous wave.

[IshKebab]

I think David Chisnall's article is very good. However I don't think you should oversell the few issues with RISC-V. There are definitely some design mistakes, but overall it is good. I would say as good as ARM (but not as mature yet).

Also... consider how successful an insane instruction set like x86 is! The ISA definitely matters for performance, but it clearly doesn't matter that much.

Also the uniformity of the ISA is very nice for compilers. Sure in practice you're only ever going to use x1 or x5 for your return address but adding the hard constraint that you can only use those is definitely going to complicate some software.

I'm not sure what you mean about fighting fragmentation. I used to think that but I didn't know about the RVA profiles.

[fwsgonzo]

Indeed, I think he's repeating something that is today outdated information. With RVA profiles, we know what desktop-class RISC-V looks like, and that's what people might compare against ARM.

[akira2501]

> Avoiding flags also has some interesting effects on encoding density.

That's one thing I liked about the Mill CPU was the belt, but I thought it was misplaced for data, and would be a great way to just carry the FLAGS register instead.

This would make conditional testing much easier and would mean you don't have to be as concerned about intermediate instructions updating flags before you use them.

I never had time to deeply think about it. Does someone want to tell me why this is actually a bad idea?