> On 1/06/2018, at 6:16 PM, Sebastian Huber
> <sebastian.hu...@embedded-brains.de> wrote:
>
> On 29/05/18 20:02, Jim Wilson wrote:
>>> Most variants include the C extension. Would it be possible to add
>>> -march=rv32g and -march=rv64g variants?
>>
>> The expectation is that most implementations will include the C extension.
>> It reduces code size, improves performance, and I think I read somewhere
>> that it takes only 400 gates to implement.
>>
>> It isn't practical to try to support every possible combination of
>> architecture and ABI here, as there are too many possible combinations. But
>> if there is a major RISC-V target that is rv32g or rv64g then we should
>> consider it. You can of course define your own set of multilibs.
>
> I am not a hardware developer, but I heard that the C extension is not easy
> to implement in out of order machines.
Easy is relative.
The RISC-V ISA encoding has been designed so that wide fetch is relatively
easy, possibly an order of magnitude easier than an ISA with a complex variable
length encoding like x86.
RV64GC instruction lengths can be derived from the 2 least significant bits in
the first half-word packet of each instruction for mixed 16/32 bit
instructions. It does not require an attempt to parse multiple prefixes with
instructions ranging from 1 byte up to 15 bytes, before arriving at an
instruction length (x86). From that perspective RV64GC is decidedly simple.
That said, RV64GC is a little more complex than regular 32-bit encodings like
RV64G, PowerPC, AArch64, or SPARC.
I don’t think the paper you have linked to draws the conclusion you are
arriving at. I spoke to Chris Celio about RVC and he said he just just didn’t
get around to implementing RVC in BOOM, not necessarily that it’s absence is a
statement of its difficulty rather the academic objectives of BOOM, one of a
very small number of Open Source OoO processors. Sure, if it was “trivial” then
BOOM would include it, so it’s certainly non trivial.
For BOOM, RVC requires an instruction buffer that handles unaligned fetches and
the way the PC is derived further down the pipeline needs to be modified as the
same micro-op may have a different width depending on whether it was expanded
from an RVC encoding. It may or may not an extra pre-decoder pipe stage. I have
a fair understanding of what’s requested. The misaligned fetch is probably the
most complex but BOOM already needs to have complex cases like the fetch buffer
spanning cache lines and page boundaries. Unaligned instruction fetches add to
this.
> For example:
>
> https://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-157.html
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
