Home Original page

[PATCH] RISC-V: Branches of vector extension are not merged into binutils mainline

Palmer Dabbelt palmer@dabbelt.com
Fri Jul 31 02:19:38 GMT 2020 
On Mon, 27 Jul 2020 15:07:42 PDT (-0700), Jim Wilson wrote:
> On Sun, Jul 26, 2020 at 9:47 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> Jim and Kito are correct: the policy is to only support ratified extensions in
>> most of the RISC-V software ports.  It sounds like 0.7.1 is planned on being
>> incompatible with the vector extension is eventually ratified, so in this case
>> we would not accept support for it in most of the upstream repositories.
>
> There was a serious compatibility break immediately after 0.7.1, and
> many more since.  There are thousands of instruction differences
> between 0.7.1 and what will be the official V extension, and some
> fundamental core architecture differences.  It won't be practical to
> support both 0.7.1 and the official V spec as a single extension.
>
>> While I don't want to speak for anyone else here, I've started to come to the
>> conclusion that this policy is not having the intended effects.  Specifically:
>> Right now it is necessary to have non-standard ISA extensions in order to build
>> any viable RISC-V based system.  As a result our policy of only accepting
>> standard RISC-V extensions is actually resulting in more fragmentation, as
>> everyone has custom ISA extensions and therefor everyone must have their own
>> software stack as well.
>
> I think custom ISA extensions is a different problem from non-ratified
> extensions.  If we wanted to support the SiFive cache control
> instructions for instance that should be doable, as SiFive isn't going
> to be deliberately incompatible with itself.  We just need to add an
> option, or an arch extension like Xsifive, to enable them.  Or maybe
> tie them to -mpu=X options.  But if we have multiple vendors
> implementing different versions of the non-ratified V spec, then we
> will have multiple vendors deliberately incompatible with each other,
> while all claiming to have V support.  That isn't something that we
> can support.

That's a good point -- one of the big problems with the draft extension is that
they're usually pretty ambiguous, so implementations from multiple vendors are
likely to be incompatible with each other.  Custom extensions do at least solve
that problem, as compatibility is just up to the vendor.  In a sense that's
really what we do for every other ISA, as it's really up to the hardware
vendors to deal with compatibility between various generations of their
implementations.

The other big issue with supporting anything that hasn't been ratified by the
RISC-V foundation is: where do we draw the line as to what we accept?

>> I don't think this is a major issue right now because the current set of
>> practical RISC-V systems are of the scale where inherently portable software
>> stacks just aren't sensible
>
> Linux builds fine using portable software stacks.  The only issue I'm
> aware of is that the SiFive freedom-e-sdk requires the SiFive
> toolchain, because freedom-e-sdk requires clic support, even when
> targeting a core that doesn't have clic support.  We haven't
> upstreamed clic support because the fast interrupt spec isn't ratified
> yet.

Linus' tree builds with the FSF GCC, but that's because we enforce the same
constraints there as we do here.  Every available Linux-capable ASIC is based
on Rocket, so it's not like supporting both of them is much of a feat (and they
use incompatible privileged specifications, though in ways that aren't relevant
to the toolchain and aren't particularly interesting).  I know we rejected the
Andes' port because it had custom stuff in it, so there's at least some Linux
stuff floating around out of tree.

I'm way more worried about the embedded stuff, though.  As far as I can tell,
most RISC-V development right now isn't for Linux-based systems and they all
have some degree of non-standard extensions.  All the actual code I can find
has trivial non-standard stuff (numbered CSRs and .insn stuff), but the
marketing material alludes to much more complicated extensions and associated
custom toolchains for support.  I assume that at least some of that is real,
but maybe I just haven't properly learned my lesson about listening to the
marketing people ;)

> I do agree that we are starting to have a problem though, but for a
> different reason.  We have multiple non-ratified extensions that have
> been in discussion for over a year, and several new ones that are
> starting up.  This is leading to a lot of different branches.  We have
> a branch for B support.  We have a branch for V support.  We have a
> branch for clic/fast-interrupt support.  We have a branch for Zfh
> support.  We will soon need a branch for Zfinx support.  And we will
> likely soon need a branch for EABI, but that is a software feature not
> a hardware feature.  Anyways, we have too many parallel branches now,
> with some people needing support from multiple branches, e.g. a branch
> combining V and Zfh support is a necessity, which complicates
> maintenance.  It might be simpler to just maintain this stuff in the
> upstream tree instead of having lots of different branches, and maybe
> add a -mexperimental or -munofficial option or something to enable
> support for non-ratified features, with the caveat that we will not
> support experimental/unofficial features even if they appear in an
> official FSF release.  That gives us free reign to track the evolving
> specs and not worry about compatibility breaks for non-ratified
> extensions.  I'm not sure whether actually this makes anything easier
> though.  In the case of the V spec, nothing would have made that easy
> to maintain.  But for the others, the changes have been mostly small
> and incremental, and maintaining them all together would not have been
> a major issue.

That's a good point -- I'd forgotten how much of a headache it is to maintain
even simple stuff out of tree.  I suppose my assumption had been that these
branches were going to be fairly short lived, but I suppose I was a bit too
optimistic about the speed at which these ISA extensions would get finished.  I
wouldn't be opposed to carrying the various draft extensions in tree, as long
as everyone is OK with support for these being deprecated on arbitrary
timelines (ie, new drafts get released).

I'd even go so far as to say we should force a trivial source code change to
build in support for the experimental stuff -- ie, put "#define
SUPPORT_EXPERIMENTAL_EXTENSIONS 0" in riscv.h so "-mexperimental" won't even be
accepted by standard builds.  That way users can't just get support for
experimental extensions, they'd have to modify the source code so we'd have an
easy way to make sure these don't drift into software.  I'm not sure if that's
overkill, though.

I agree that this doesn't help any with the V extension, but I don't really
think there's anything we can do about that.  If extensions that require a
large code base change in fundamental ways then I don't think it's possible to
avoid lots of changes to that code base.  TBH, I don't think there's any way to
get around the V extension being a major pain point -- even if we had an ISA
right now there'd still be a huge amount of work to do, and I don't see us
having a stable ISA for a while.  Hopefully the V extension is the exception
not the rule.

> I agree with the bit about not implementing non-ratified extensions in
> ASICs.  Anyone who does that should bear the full cost of maintaining
> a toolchain for their ASIC because we shouldn't be helping people do
> that.
>
> Jim
More information about the Binutils mailing list