FWIW, I agree. It was decided prematurely at a time where all implementations were fairly
simple and for which C does not carry as much burden.
It is the greatest irony that RISC-V went to great length to avoid the
pitfalls that burden superscalar implementation - and then went on
to imposed variable length instructions, split over cache lines (*).
(*) I'm unimpressed with the claims that you "can just predict where the
boundaries are". Well of COURSE you can. But it's an extra burden,
which carries a power, area, cycletime, opportunity and verification cost.
On Apr 1, 2018, at 13:57 , Luke Kenneth Casson Leighton
On Sun, Apr 1, 2018 at 9:48 PM, Alex Bradbury <asb(a)lowrisc.org> wrote:
> On 1 April 2018 at 21:31, Richard W.M. Jones <rjones(a)redhat.com> wrote:
>> Hi, I was going to try v0.5 on my Nexys 4 DDR. However I believe
>> that this version doesn't support the Compressed extension. I
>> disassembled the sample bbl and there are no short instructions.
>> Is support for the C extension available and/or planned?
> Hi Richard,
> Thanks for taking a look. You're correct that we're currently based on
> an old version of Rocket which doesn't support the compressed
> extension - upstream refactorings have made it difficult to keep up to
> date. We do intend to support the C extension, though I can't give a
> ETA right now. Sadly this means we can't (for now) directly consume
> the awesome work you and your colleagues have been doing on Fedora
> RISC-V - but look forward to doing so in the not too distant future.
alex, dr kimmet: i... did try (partly on your behalf) to get across
to the RISC-V Foundation how... deeply unimpressed i was that RV64GC
had been chosen as the default unix standard without *any* kind of
wider consultation, not even with the RISC-V members.
unfortunately my usual direct, bluntly honest and completely
undiplomatic communications style, which i mirror in real life by
wearing 12 GBP steel toe-capped boots, bought from Douglas Dairy
Supplies in Stranraer, did not go down well.