I'm not sure that they succeeded: 32bit instructions aligned as 16bit makes decoding harder, I wonder if we're ever going to see a 8wide decoder RISC-V..
And I remember seeing here a comparison between ARM's SVE and RISC-V, I wasn't very convinced by the RISC-V vector's extension.
> I wonder if we're ever going to see a 8wide decoder RISC-V.
Considering there are 6-wide x86 cores on the market, I wouldn't be too concerned about RISC-V going wide. The instruction length decode is a 2-bit dependency chain; whereas the renamer-dependency logic builds off of 5-bit register values, which will be the bigger bottleneck.
Note that RISC-V's compressed instructions are trivially decoded with the first 2-bits; there is no further wonkiness about needing to decode the whole instruction before you can know it's true length that can be seen in other ISAs.
It'll be interesting to see how feature support vs the ISA extension system plays out for RISC-V. IIRC, the main reason for the 32-bit instruction vs 16-bit width is the compressed extension, which got stuffed into the "general" extension family. Having worked on a (simulated) RISC-V decoder myself, they stuck out like a sore thumb, in fact I think some microarchitectures literally pawn this extension off to it's own functional unit entirely.
It would probably be tedious—but not impossible—to write a tool which literally replaces the compressed instructions with their full length variants in an ELF (and then recalculates any offsets as needed).
I'd be very curious to see the performance tradeoffs between BOOM and some sort of big/little RISC-V microarchitecture on benchmarks compiled with and without compressed instruction support.
> which got stuffed into the "general" extension family
No it didn't. That's why Linux Distributions say they are RV64GC, for general+compressed.
The original encoding set was done by Andrew Watermen to be implemented in the minimal amount of gates. And he was successful.
So of course any change would stick out like a sore thumb. That however does not mean its bad. For reasonable performance code cores it is well worth it because you get many benefits, not just code size. There is a reason that all systems that expect reasonable performance have adopted the C instruction as a standard, decoding is tiny part of the chip at that point.
Even some very tiny cores prefer as the price of slightly more decoder complexity is worth it compared to the code size.
I suggest you go look threw the lectures in the RISC-V channel, I have seen a number of presentation that do such comparison if I remember correctly.
> 32bit instructions aligned as 16bit makes decoding harder
That's an optional extension, and the gains in code density make it worthwhile in many cases. It's certainly a lot better designed than many other variable-length ISA's.