Re:Can MIPS Leapfrog RISC-V?
by snvzz on Friday March 22, 2019 @02:32PM
(#19465487)
>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.
Re:Can MIPS Leapfrog RISC-V?
by TomVDB on Friday March 22, 2019 @03:23PM
(#19465977)
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!
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.