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

[Palmer Dabbelt]

On Wed, 08 Jul 2020 11:09:33 PDT (-0700), Jim Wilson wrote:
> On Wed, Jul 8, 2020 at 5:44 AM <jiejie_rong@c-sky.com> wrote:
>> From version rule of RISCV extension, we should include stable version from the first v0.7.1,
>> riscv official announce that stable version can be used for implementation and evaluation.
>
> The v0.7.1 draft of the vector extension has no official status.  The
> "stable" version was for experimental purposes.  The vector extension
> was evolving so rapidly that people were having trouble evaluating it,
> so a version was marked as "stable" for people to do experimental
> toolchain, simulator, and vector math library ports to evaluate it,
> and then feedback from those experiments were used for further
> evolution of the vector extension proposal..  It was never meant to be
> implemented in hardware.
>
>> We could set the latest as default and absorb other implementation who follow the old vector spec also :)
>
> Unfortunately there is no useful compatibility between the obsolete
> v0.7.1 draft and the current draft of the vector extension.  Hundreds
> of instructions have been dropped, added, assembly syntax changed,
> encoding changed, constraints changed, semantics changed.  And
> fundamental features of the extension have changed such as valid
> register sizes, element sizes, numbering of lanes within a register,
> encoding of vector masks, etc.  If we need to implement both the
> v0.7.1 draft and the current draft, then we probably have to treat
> them as two different incompatible vector extensions.  Then there is
> the problem that it is just Nelson and me doing binutils work, and
> Kito and me doing gcc work, and we don't have enough bandwidth to
> maintain two different incompatible vector extensions.
>
> GCC has the concept of vendor branches.  I would suggest that if you
> really want upstream support for your vector extension, that you
> create a vendor branch for it and maintain it yourself.  This means
> that linux distros won't have your vector support, but you can build
> your own toolchains and maybe your own linux distros to solve that
> problem.

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.  We
decided on this policy a few years ago for a handful of reasons, including:

* The maintainers of the various bits of RISC-V systems software are extremely
  oversubscribed.  Maintaining draft extensions dramatically increases the
  support burden on the maintainers.
* We were well aware of the fragmentation that arose around other ecosystems
  and wanted to avoid it.  Limiting upstream software to supporting official
  extensions encourages vendors to interact with the RISC-V foundation, which
  we hoped would limit fragmentation.
* RISC-V is owned by the foundation, and while the draft specifications do have
  a degree of association with the RISC-V foundation they have not been
  officially accepted into the RISC-V cannon and therefor haven't been
  subjected to the same degree of scrutiny as the ratified specifications.  As
  a result we assume that there will be more compatibility issues between
  implementations of draft extensions than of ratified extensions, which would
  make maintaining binary compatibility difficult in the long term.

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 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 -- ie, if you want to run something like FreeRTOS
then you're probably used to using a vendor's SDK (though I do kind of hate
admitting that).  Shipping a custom toolchain does increase the effort required
to ship these SDKs, but as it currently stands the patches tend to be somewhat
self-contained and therefor aren't terribly hard to maintain out of tree.

That said, having a bunch of vendor-specific toolchains does put a burden on
the entire RISC-V ecosystem.  I can buy the argument that open source
maintainers are always going to be oversubscribed as that's just the nature of
the job, but I think we are shooting ourselves in the foot on that front: by
requiring vendors to fork the toolchain we are providing no incentive to work
upstream, which means less help for the maintainers.  To a certain degree
there's nothing we can do about vendors shipping their own toolchains, right to
fork and such, but I consider open-source distributions shipping
vendor-specific patches a pretty strong sign that we're doing something wrong.

Changing this policy would require a lot more discussion and I'm not even ready
to agree to it yet, I think I would be willing to change my mind if the first
round of high-volume silicon that is meant to run a portable software stack
requires a custom toolchain for the base functionality required to build a
useful system.  This opens a big can of worms so I'm still holding out hope
that it doesn't happen, but given the timelines involved in building hardware
and stabilizing ISA extensions I think it's becoming increasingly likely that
we'll have to confront the issue at some point.  I'd rather have something that
works than something that's intellectually pure, but I'm more of a toolchain
user than a toolchain maintainer these days so I'm not sure how much my opinion
means any more.

I'll still be mad about the non-standard extensions, though, so please try to
build hardware that implements ratified specifications ;)

> You also need to stop calling this the V extension because it isn't.
> You need to call it something like Zv071 or Zvalibaba to make it clear
> that it is a vector extension but not the official one.

I kind it hard to keep up with the naming schemes, but IIRC Z is for standard
extensions, while X is for custom ones?  Doesn't really matter though: either
way, I definitely agree that calling anything "the RISC-V V extension" before
something is ratified is nonsense -- that would hold true for any extension,
but it's particularly true for the V extension as due to the complexity it
keeps dramatically changing.