Hacker News Reader

Comment by api | Hacker News Reader

The ISA fragmentation issue is the worst thing I've consistently heard about RISC-V.

Fragmentation is in general horrible. It was a major problem with ARM32, and that was much more strictly defined with less variation. ARM64 tried to define things more rigidly and has mostly banished the problem. The ARM ecosystem continues to be held back though by fragmentation around bootstrapping, hardware enumeration, and other aspects of the system that surround the core. Every ARM board tends to be a special snowflake.

I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.

View on HN

> I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.

They're working on this right now. Niche applications can still do their thing, but there will be standard profiles for e.g. a "Linux class" application processor, or an "ARM Cortex-M*" equivalent micro-controller.

They need to be sure there are as few of these targets as possible. I'd suggest one 32-bit and one 64-bit, period.

Think of it like this: the difficulty of targeting RISC-V increases with the square of the number of variants.

It's a general rule in systems that difficulty and bugs increase exponentially, not linearly, as complexity increases.

That's really cool, I had no idea!

Did a quick search on this, and I believe the Linux portion of this is the responsibility of the "UNIX-Class Platform Specification Task Group" [1]. They seem to be quite active, which I'm reading as a sign things are progressing.

[1]: https://lists.riscv.org/g/tech-unixplatformspec

Right you are, that's the group responsible. It's something of a priority for RISC-V international right now, because of exactly this worry.

RISC-V International is sometimes really bad at communicating that it's working on these problems. But odds on, they usually are.

> I can't imagine RISC-V beyond niche applications unless someone publishes a more strictly specified version of it that provides a unified platform.

What do you think `RV64GC` is?

RV64GCV, RV32IMAC, etc are all short-hand describing the supported capabilities of a given RISC-V CPU.

ARM has different specs for each type of core. https://en.wikipedia.org/wiki/ARM_Cortex-M

Compilers have handled this for years.

I think RISC-V is converging on a standard “this is what a ‘big’ core looks like”, but with the possibility that you stick a tiny RISC-V core on an IC somewhere.

Hardware enumeration IMO can be harder than dealing with ISA variations. (And to my knowledge, RISC-V hasn’t solved any hardware enumeration problems.)

It's also not true, unless you also consider that x86 is fragmented. RISC-V Intl has defined two platform specifications with apparently more to follow. Those will define a set of extensions which are required, and the rest will be probed at runtime, which is exactly how x86 works.

I see so many comments here about RISC-V fragmentation. This is not my expertise, so correct me if I am wrong, but if this means that the particular RISC-V CPU has to be able to execute some instruction, from what I understand the RISC-V designers expect to happen is missing instructions will be implemented in software.

So if the CPU runs into an instruction that it doesn't understand, this will trigger a missing instruction trap and software can implement the instruction. Fragmentation problem solved, no?

Reply on news.ycombinator.com