Re: [PATCH 3/7] RISC-V: Support new GAS options and configure options to set ISA versions.

[Nelson Chu <nelson.chu@sifive.com>]

Hi Palmer,

On Fri, Apr 24, 2020 at 6:59 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > * -mriscv-isa-version = <ISA-string>
> > The syntax of <ISA-string> is same as -march option, but without rv32 or rv64
> > prefix.  There are two reasons that you may need this option,
> >
> > 1. Some versions of extensions defined in the ISA spec are not matched to the
> > toolchain’s implementation.  For example, V-ext is defined to version 0.7 in
> > ISA spec, but we only have implementations for 0.8 and 0.9.  Therefore, you
> > have to use this option to choose the correct version for V-ext.
> >
> > 2. You want to update the version for the specific standard extensions if the
> > version are not set in the ELF arch attributes and -march option.
>
> I don't buy the argument for this.  The V extension stuff isn't relevant: those
> are all draft versions, and this is a perfect reason why we don't want to take
> drafts upstream.   When we have a defined V ISA it'll be part of a versioned
> RISC-V specification and any users that want it can just use at least that ISA
> spec.

I think I got your point, we all have reached consensus that it's
better not to take draft spec upstream.  The v-extension might be a
little different, the latest released ISA spec defines the v-ext as
0.7, even if the released riscv-v-spec is up to 0.8.  According to our
consensus, we should accept the 0.8 and 0.9 v-ext on upstream until we
have a released ISA spec defining them.  Otherwise, we can just accept
the 0.7 v-ext for now.  I guess that is why we just have v-ext 0.8 and
0.9 on riscv/riscv-binutils-gdb rather than upstream.  This makes
sense, thank you :)

And we can still use -march to choose the version we want, including
v-ext.  If users use the rvv-0.9.x in riscv/riscv-binutils-gdb, they
have to set the v-ext with version 0.9 by -march.  Otherwise, we will
give them v0p0 if they only set -misa-spec=20191213.

> For the second argument, why not just provide those via -march?  I can buy that
> it's a pain to build up valid -march strings in build scripts, but this just
> fixes a specific instance of that problem (and that's not going to be that
> common, as most users just want a single ISA version).

Umm I have to think about this again.

> I haven't really looked at the code, as dropping this will change the patches pretty drasticly.

Yes dropping this need to rewrite the code structure.  I must think
about that if we can have a better solution to reduce the overhead of
-march setting in the build script.


Thanks for the suggestions, they are really helpful :)
Nelson