4 ms·
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 wid
by dwrodri 5y ago
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.
- nickik 5y ago> 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.