3 ms·

Genuine question related to riscv: what is the value of a standard when a majority of it is part of optional extensions? Doesn't that make riscv a ton of distin

by tntn 8y ago

Genuine question related to riscv: what is the value of a standard when a majority of it is part of optional extensions? Doesn't that make riscv a ton of distinct standards, marketed as one? RV32I is nothing close to RV64IMAFDQCPBS. It seems like all the fragmentation standards are made to avoid packaged up as a "standard" to make sure everything under the sun can use risc-v. (see also usb-c)

benj111 8y ago
They're designed to cover a lot of different processor types. Servers have different needs to microcontrollers. Nevertheless you would expect code that works on the microcontroller, to scale up and work on the server so there is some value. You probably don't need to same code to run on such differing hardware though. The value is in your code working on 2 processors with optional FPUs. I don't think you're ever going to get to USB levels of plug and play, but you don't really need that. Edit: So yes you might get usb 3/c/whatever levels of confusion, but you don't swap processors multiple times a day so not really a problem.
TomVDB 8y ago
Many of the optional extensions are either trivial to implement (think multiplier/divider) with minimal logic or are almost considered standard by now (e.g. compressed, because code size is critical for embedded CPUs) For now, the vast majority of RV CPUs will go into embedded CPUs, where an extension is a compile switch away. In practice, I think all embedded CPUs will be RV32IMAC. For bigger CPUs, it's pretty simply: almost all them will be RV64GC. ISA fragmentation is nothing new: x86 and ARM don't seem to have a problem with them, and one could easily argue that those are way more fragmented than RV right now.
- snvzz 8y ago
  >RV32IMAC Or RV32IMAC+some extension that makes sense for the application. There's also a non-defined but planned RV32E for embedded. >RV64GC I suspect this will be the case at first, then a superset will take over. e.g. bitfield operations extension and vector extension are unlikely not to be taken advantage of by e.g. Debian. Likely resulting in a few arch variants with increasingly more such extensions, such as further adding DSP and JIT extensions. It should be a bit messy at first, and calm down later when there's a lot of frozen extensions that handle most popular tasks. If anything, I fear calling the 'G' subset was premature. That we're already talking about RV64GC and not just RV64G does strongly point to that.
  - TomVDB 8y ago
    When you deal with complex telecom chips on 28nm and smaller on a daily basis, it's hard to imagine that a resource savings of just 512 FFs (the difference between RV32E and RV32I) is worth the trouble!
nerpderp82 8y ago
IS fragmentation is a red herring. We already have it, it somewhat of a nuisance, but RV doesn't make it worse.

by tntn 8y ago

benj111 8y ago

They're designed to cover a lot of different processor types. Servers have different needs to microcontrollers. Nevertheless you would expect code that works on the microcontroller, to scale up and work on the server so there is some value. You probably don't need to same code to run on such differing hardware though. The value is in your code working on 2 processors with optional FPUs. I don't think you're ever going to get to USB levels of plug and play, but you don't really need that. Edit: So yes you might get usb 3/c/whatever levels of confusion, but you don't swap processors multiple times a day so not really a problem.

TomVDB 8y ago

Many of the optional extensions are either trivial to implement (think multiplier/divider) with minimal logic or are almost considered standard by now (e.g. compressed, because code size is critical for embedded CPUs) For now, the vast majority of RV CPUs will go into embedded CPUs, where an extension is a compile switch away. In practice, I think all embedded CPUs will be RV32IMAC. For bigger CPUs, it's pretty simply: almost all them will be RV64GC. ISA fragmentation is nothing new: x86 and ARM don't seem to have a problem with them, and one could easily argue that those are way more fragmented than RV right now.

snvzz 8y ago
>RV32IMAC Or RV32IMAC+some extension that makes sense for the application. There's also a non-defined but planned RV32E for embedded. >RV64GC I suspect this will be the case at first, then a superset will take over. e.g. bitfield operations extension and vector extension are unlikely not to be taken advantage of by e.g. Debian. Likely resulting in a few arch variants with increasingly more such extensions, such as further adding DSP and JIT extensions. It should be a bit messy at first, and calm down later when there's a lot of frozen extensions that handle most popular tasks. If anything, I fear calling the 'G' subset was premature. That we're already talking about RV64GC and not just RV64G does strongly point to that.
- TomVDB 8y ago
  When you deal with complex telecom chips on 28nm and smaller on a daily basis, it's hard to imagine that a resource savings of just 512 FFs (the difference between RV32E and RV32I) is worth the trouble!

nerpderp82 8y ago

IS fragmentation is a red herring. We already have it, it somewhat of a nuisance, but RV doesn't make it worse.