4 ms·
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. com
by 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 agoWhen 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!