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

[Jim Wilson]

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.

> 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.

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.

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