RISC-V ELF multilibs

[Michael Clark]

> On 1/06/2018, at 6:16 PM, Sebastian Huber <sebastian.huber@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.huber@embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>