3 ms·

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, a

by api 6y ago

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.

bem94 6y ago
> 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.
- api 6y ago
  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.
- yoshuaw 6y ago
  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 https://lists.riscv.org/g/tech-unixplatformspec
  - bem94 6y ago
    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.
klodolph 6y ago
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.)
rwmj 6y ago
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.
mperham 6y ago
> 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 https://en.wikipedia.org/wiki/ARM_Cortex-M Compilers have handled this for years.
ajanicij 6y ago
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?

by api 6y ago

bem94 6y ago

> 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.

api 6y ago
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.
yoshuaw 6y ago
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 https://lists.riscv.org/g/tech-unixplatformspec
- bem94 6y ago
  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.

klodolph 6y ago

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.)

rwmj 6y ago

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.

mperham 6y ago

> 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 https://en.wikipedia.org/wiki/ARM_Cortex-M Compilers have handled this for years.

ajanicij 6y ago

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?