Support newer ISA spec version for toolchain

[Kito Cheng]

Hi all:

Since the latest spec draft has changed the rule of arch string and added Z* extension, it cause some incompatible issue between 2.2 and later version.

1. Parsing order changed: x, s, sx in 2.2, but s, x in latest spec. 

https://github.com/riscv/riscv-gnu-toolchain/issues/484

2. IMA in 2.2 equivalent to IMAZicsr_Zifencei in latest.

  - This might lead unexpected behavior when people upgrading toolchain.

There is two solution for the above two issues:

- Introduce new option to control the version of ISA spec.

- Only support latest spec on toolchain.

And for first issue, Alex also propose we might relax the parsing rule in toolchiain to accept both order.

3. How to identify which version are used for object/execrable/library.

And last issue is how to identify the version, it might not big problem now,

since there is no big incompatible issue yet, but we should solve this problem 

before things get worse.

My proposal is add new field in ELF attribute to record ISA spec version, and let linker or run-time env to resolve/detect the incompatible things.

----------------------------------------------------------------------------

For GNU toolchain side, I plan to add extra configure option --with-riscv-isa-spec= to control the default ISA spec version in toolchain, 

And add another configure option --with-riscv-isa-version=<isa-with-versions> to provide a way fine tune the default version of each ISA extension.

Reference:

[1] Extension parsing order: "x, s, sx" vs "s, sx, x": https://github.com/riscv/riscv-gnu-toolchain/issues/484

[2] Canonical order for Z* extensions https://github.com/riscv/riscv-isa-manual/issues/415

[3] Patch for support Z* extension parsing on binutils https://sourceware.org/ml/binutils/2019-07/msg00285.html

 

[Jim Wilson]

On Fri, Aug 2, 2019 at 1:13 AM Kito Cheng <kito....@gmail.com> wrote:
> 1. Parsing order changed: x, s, sx in 2.2, but s, x in latest spec.
> https://github.com/riscv/riscv-gnu-toolchain/issues/484

Andrew Waterman tells me that there are no current s or sx extensions,
so in theory the change should not affect anyone. We can probably
just accept the new order and drop support for the old order and for
the old sx extensions.

> 2. IMA in 2.2 equivalent to IMAZicsr_Zifencei in latest.
> - This might lead unexpected behavior when people upgrading toolchain.

I don't know what to do about that yet. I doubt that people will want
to specify z extensions when using a -march option.

> There is two solution for the above two issues:
> - Introduce new option to control the version of ISA spec.

I think this is useful anyways. We have some csrs that exist in one
version of the spec but not in other versions, and we have no way to
represent that. Some csrs are directly tied to an extension like the
hypervisor csrs, but some aren't, and can only be properly handled if
we have a way to give the ISA spec version.

> My proposal is add new field in ELF attribute to record ISA spec version, and let linker or run-time env to resolve/detect the incompatible things.

I think this is a good idea.

> For GNU toolchain side, I plan to add extra configure option --with-riscv-isa-spec= to control the default ISA spec version in toolchain,
> And add another configure option --with-riscv-isa-version=<isa-with-versions> to provide a way fine tune the default version of each ISA extension.

This sounds reasonable to me.

Jim

[Maxim Blinov]

Hi all,

I have an implementation of binutils available that provides this functionality. I posted it on binutils mailing list, but then it wasn't very complete, and I have a complete version of it now (except elf attrib stamping.)

I wrote about it here: https://sourceware.org/ml/binutils/2019-08/msg00010.html, but please don't use this version, its now out of date.

Since then I've actually added the -misa-spec flag functionality, and that version is here:

https://github.com/mablinov/riscv-binutils-gdb.git

please see branch "multi-spec-opt" (or should I just send patch to mailing list?)

It is kept up to date with head of trunk, and there is a single commit on top that adds this parsing stuff.

With the above version, invoking the following is allowed:

riscv32-unknown-elf-as -misa-spec=2.2 -march=rv32imafd_xargle_s_sxargle -o t1-a.o t1-a.s

(order x, s, sx)

but as of 2.3 (i know this version doesnt exist, its just placeholder for the new s, sx, z, x parse order) its not allowed:

riscv32-unknown-elf-as -misa-spec=2.3 -march=rv32imafd_xargle_s_sxargle -o t1-a.o t1-a.s

Assembler messages:

Fatal error: -march=rv32imafd_xargle_s_sxargle: unexpected ISA string at end: s_sxargle

Only the new order works:

riscv32-unknown-elf-as -misa-spec=2.3 -march=rv32imafd_s_sxargle_xargle -o t1-a.o t1-a.s

Furthermore, as mentioned in the above mailing list entry, the code now checks for alphabetical ordering within all subset groups (s, sx, x, and z),

and complains about all duplicates.

What does everyone think of this implementation? I did write this anticipating that we would preserve the old way of parsing, but it seems like no one depends on the old way of parsing. The rest of the parsing code is still an improvement I think, since it catches duplicates and wrong order, etc.

[Alex Bradbury]

On Thu, 8 Aug 2019 at 11:28, Maxim Blinov <maxim....@embecosm.com> wrote:
>
> Hi all,
>
> I have an implementation of binutils available that provides this functionality. I posted it on binutils mailing list, but then it wasn't very complete, and I have a complete version of it now (except elf attrib stamping.)
>
> I wrote about it here: https://sourceware.org/ml/binutils/2019-08/msg00010.html, but please don't use this version, its now out of date.
>
> Since then I've actually added the -misa-spec flag functionality, and that version is here:
>
> https://github.com/mablinov/riscv-binutils-gdb.git
> please see branch "multi-spec-opt" (or should I just send patch to mailing list?)
> It is kept up to date with head of trunk, and there is a single commit on top that adds this parsing stuff.
>
> With the above version, invoking the following is allowed:
> riscv32-unknown-elf-as -misa-spec=2.2 -march=rv32imafd_xargle_s_sxargle -o t1-a.o t1-a.s
>
> (order x, s, sx)
> but as of 2.3 (i know this version doesnt exist, its just placeholder for the new s, sx, z, x parse order) its not allowed:
> riscv32-unknown-elf-as -misa-spec=2.3 -march=rv32imafd_xargle_s_sxargle -o t1-a.o t1-a.s
> Assembler messages:
> Fatal error: -march=rv32imafd_xargle_s_sxargle: unexpected ISA string at end: s_sxargle
>
> Only the new order works:
> riscv32-unknown-elf-as -misa-spec=2.3 -march=rv32imafd_s_sxargle_xargle -o t1-a.o t1-a.s
>
> Furthermore, as mentioned in the above mailing list entry, the code now checks for alphabetical ordering within all subset groups (s, sx, x, and z),
> and complains about all duplicates.
>
> What does everyone think of this implementation? I did write this anticipating that we would preserve the old way of parsing, but it seems like no one depends on the old way of parsing. The rest of the parsing code is still an improvement I think, since it catches duplicates and wrong order, etc.

Thanks for sharing Maxim. What is the behaviour if conflicting version
numbers are specific in the -march ISA naming string? e.g.
-misa-spec=2.2 but rv32i2p0?

I'm a +1 on -misa-spec (thanks for bringing this issue to the list Kito).

Best,

Alex

[Maxim Blinov]

Hi Alex,

 

What is the behaviour if conflicting version
numbers are specific in the -march ISA naming string? e.g.
-misa-spec=2.2 but rv32i2p0?

I'm not sure about that example - I had a look at the 2.2 spec, https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf

and the integer subset for riscv-32 is version 2.0. So that should be compatible, right? Or are we going to make the version of the subset

ISA's (i, m, a, f, ... n) all simply reflect the -misa-spec version?

But in any case, my branch currently only worries about difference in parsing order, and there is no subset version checking (e.g. you can still

pass "-misa-spec=2.2 -march=rv32i9999p999".

I'll add version checking for known -misa-spec versions.

Another question I had: For the 's' extension, am I correct in thinking that 's' on its own is legal (supervisor extension), and also 's'-prefixed extensions *may* exist in the future? Atleast, for the current draft spec. I had a look at the draft supervisor spec, and couldn't find any concrete extension names.

Also, for the latest draft spec, now that rv32i2p1 also includes the Zifencei extension, should the following throw an error?

"-march=rv32i2p1_Zifencei"

since 2p1 already includes Zifencei?

Maxim

[Alex Bradbury]

On Thu, 8 Aug 2019 at 12:48, Maxim Blinov <maxim....@embecosm.com> wrote:
>
> Hi Alex,
>
>>
>> What is the behaviour if conflicting version
>> numbers are specific in the -march ISA naming string? e.g.
>> -misa-spec=2.2 but rv32i2p0?
>
>
> I'm not sure about that example - I had a look at the 2.2 spec, https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
> and the integer subset for riscv-32 is version 2.0. So that should be compatible, right? Or are we going to make the version of the subset
> ISA's (i, m, a, f, ... n) all simply reflect the -misa-spec version?

I meant to refer to the ratified version of the spec - which you'd
think would be 2.3 but it seems has no version number? That might be
problematic, as -misa-spec=20190608 isn't all that convenient or
memorable.

Best,

Alex

[Andrew Waterman]

We repeatedly received feedback that "ISA version" and "document version" were being conflated, and so we started versioning the document differently from the ISA.  Clearly, that has caused some confusion itself.  The Preface of the document indicates the versions of the base and extensions, which retain the earlier 2.x scheme.

 

Best,

Alex

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH296hswRJfLrgwaxLBf1eKs1nDRiz1XPYtA0pAU%2Bct40ZjQ%40mail.gmail.com.

[Kito Cheng]

Hi Andrew:

> We repeatedly received feedback that "ISA version" and "document version" were being conflated, and so we started versioning the document differently from the ISA. Clearly, that has caused some confusion itself. The Preface of the document indicates the versions of the base and extensions, which retain the earlier 2.x scheme.

So according the preface in the document, there is 2.0, 2.1, 2.2 and
then 20190608-Base-Ratified, and the future version scheme of
documentation is <date>-Base-Ratified?

[Maxim Blinov]

Hi Andrew,

We repeatedly received feedback that "ISA version" and "document version" were being conflated, and so we started versioning the document differently from the ISA.  Clearly, that has caused some confusion itself.  The Preface of the document indicates the versions of the base and extensions, which retain the earlier 2.x scheme.

Can I check that I understand this right?

The current document version that defines the RISC-V ISA is version 2.2

The latest document version that defines the RISC-V ISA is version 20190730-draft.

And finally, the owners of the RISC-V document will eventually release the next stable document version,

and it will be version 2.3.

The current base RISC-V ISA version is 2.0 (as defined by document version 2.2)

The latest base RISC-V ISA version is 2.1 (as defined by document version 20190730-draft)

And the next version of the document, version 2.3, will also probably define the base RISC-V ISA version to be 2.1 (but impossible to foretell at this point in time.)

Maxim

[Kito Cheng]

Hi Alex, Maxim:

My thought is -misa-version specify the default version of each ISA
extension, so -march can override the default version,

For example:
-march=rv32im3p0fc -misa-version=2.2 = rv32_i2p0_m3p0_f2p0_c2p0
-march=rv32im3p0fc -misa-version=2.3 = rv32_i2p3_m3p0_f2p2_c2p0

> Also, for the latest draft spec, now that rv32i2p1 also includes the Zifencei extension, should the following throw an error?
>
>"-march=rv32i2p1_Zifencei"
>
> since 2p1 already includes Zifencei?

No, rv32i2p1 didn't include Zifencei, but rv32i2p0 included, fence.i
and csr are pull out from i after i2p1

[Maxim Blinov]

Hi Alex, Maxim:

My thought is -misa-version specify the default version of each ISA
extension, so -march can override the default version,

For example:
-march=rv32im3p0fc -misa-version=2.2 = rv32_i2p0_m3p0_f2p0_c2p0

-march=rv32im3p0fc -misa-version=2.3 = rv32_i2p3_m3p0_f2p2_c2p0

It should set the defaults, but I don't think letting the user override the extension versions is the right thing to do. The risc-v document version 2.2 specifies that the M extension is version 2.0. Hence, anything else should be an error. It would be strange if the program loader saw "-misa-version=2.2 -march=rv32im3p0" in the elf attribute.

I think it should only be legal to request -march extensions and extension versions that match that particular -misa-version directive. If the user doesn't provide a -misa-version, we just default to whatever that release of binutils/gcc specifies (right now probably 2.2, in the future 2.3).

So, if the user writes "-march=rv32im3p0fc" it should error and say "ISA spec version 2.2 (the default) expects m version 2p0, instead got 3p0".

And if the user writes "-march=rv32i2p1" on an old binutils version that has -misa-version defaulted to 2.2, it fails saying "expected i version 2.0, got 2.1"

But if the user writes "-misa-version=2.3 -march=rv32i2p1" on an old binutils, or "-march=rv32i2p1" on a version of binutils that sets the default -misa-version directive to 2.3, it succeeds.

If the user wants something weird or non standard, we promise to never check the X and SX version numbers. If the user doesn't provide X and SX version numbers,

we use the same ones as whatever is the -misa-version is set to (be it default or explicit) for that version of binutils (2.2, 2.3, whatever).

So providing

"-misa-version=2.2 -march=rv32i_xcool"

or

"-march=rv32i_xcool" (-misa-version defaulted to 2.2)

will define xcool2p2,

and providing

"-misa-version=2.3 -march=rv32i_xcool"

will define xcool2p3.

Maxim

[Andrew Waterman]

2019xxxx is a version of the document. 2.x is a version of a base ISA or extension. The document version increments frequently, because the document keeps improving even when the ISA doesn’t change. Toolchains should not use the document version for anything.

[Andrew Waterman]

On Thu, Aug 8, 2019 at 6:18 AM Maxim Blinov <maxim....@embecosm.com> wrote:

Hi Andrew,

We repeatedly received feedback that "ISA version" and "document version" were being conflated, and so we started versioning the document differently from the ISA.  Clearly, that has caused some confusion itself.  The Preface of the document indicates the versions of the base and extensions, which retain the earlier 2.x scheme.

Can I check that I understand this right?

The current document version that defines the RISC-V ISA is version 2.2

The latest document version that defines the RISC-V ISA is version 20190730-draft.

And finally, the owners of the RISC-V document will eventually release the next stable document version,

and it will be version 2.3.

Hi Maxim - I think my email to Kito might have clarified this to some extent, but no, we are separating the document version from the versioning of the base ISA and extensions. This is because the document keeps changing even when the ISA it is describing does not change. There’s no plan for a document version 2.3 ever; the plan is to keep using YYYYMMDD for the document versions.

Base ISAs and standard extensions will continue using the 2.x numbering scheme.

AFAIK there is no plan to increment any of the ISA versions at this time, except the A extension will be incremented when a revised draft is ratified.

The current base RISC-V ISA version is 2.0 (as defined by document version 2.2)

The latest base RISC-V ISA version is 2.1 (as defined by document version 20190730-draft)

And the next version of the document, version 2.3, will also probably define the base RISC-V ISA version to be 2.1 (but impossible to foretell at this point in time.)

Maxim

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/ed9e9767-9e4b-41b4-a903-78b60790033d%40groups.riscv.org.

[Kito Cheng]

I've organized the issue to a list for further discussion , and item 2
and 4 is new.

item 2 was inspired by Andrew, he was asking me does it possible
treats "I" as "IZifence_Zicsr" for binutils.
For item 4, I've created a issue for that before[1], but not conclusion yet.

1. -misa-spec=[2.0|2.1|2.2|YYYYMM|YYYYMMDD]
- DD can be omitted, I assume there is no more than one releases
within 1 month.
- Interaction between -misa-spce and -march:
- Set default isa version for each extensions.
- Limit the version of ISA extensions?
- e.g. You can't use -march=rv32i2p1 -misa-spec=2.2 since it
require -misa-spec=201906
- Add one field on ELF attribute, new integer field
- Value 20/21/22 for 2.0/2.1/2.2
- Value YYYYMMDD for later version, e.g. 20190608 for
20190608-Base-Ratified.

2. Default implied Zicsr and Zifencei:
- Minimized the impact of behavior change for most use case.
- Let compiler/assembler append Zicsr and Zifencei automatically,
because this configuration is most general.
- New compiler/assembler option: -m[no-]implied-zicsr-zifencei
- New configuration option for building GNU toolchain:
--with-implied-zicsr-zifencei=[yes|no]

3. Discard old order for x, s, sx.
- We didn't have any s extension yet, so just using new order in toolchain

4. How to expanding version of G?
- G2.2 = I2p2_M2p2_A2p2_F2p2_D2p2 ?
- G2.2 = I2p0_M2p0_A2p0_F2p0_D2p0 ?
- Or other expanding scheme?

----------------- GNU Toolchain only -----------------

5. Add new configure options for building toolchain:
- --with-riscv-isa-spec= to control the default ISA spec version in toolchain,
- --with-riscv-isa-version=<isa-with-versions> to provide a way fine

tune the default version of each ISA extension.

- --with-implied-zicsr-zifencei=[yes|no] to control
-mimplied-zicsr-zifencei enable by default or not.


[1] https://github.com/riscv/riscv-isa-manual/issues/274

[Alex Bradbury]

On Tue, 13 Aug 2019 at 07:50, Kito Cheng <kito....@gmail.com> wrote:
>
> I've organized the issue to a list for further discussion , and item 2
> and 4 is new.

Hi Kito, thanks for pushing this issue forwards. Some thoughts in-line below.

> item 2 was inspired by Andrew, he was asking me does it possible
> treats "I" as "IZifence_Zicsr" for binutils.
> For item 4, I've created a issue for that before[1], but not conclusion yet.
>
> 1. -misa-spec=[2.0|2.1|2.2|YYYYMM|YYYYMMDD]
> - DD can be omitted, I assume there is no more than one releases
> within 1 month.
> - Interaction between -misa-spce and -march:
> - Set default isa version for each extensions.

I like -misa-spec as a shortcut for setting version of various
extensions. I appreciate there were confusions before about the
document versioning vs versioning for individual extensions, but
especially as the number of standard extensions grow I think it's
going to become burdensome to track each number. My hope is that most
shipping silicon will implement the versions as of a given spec
release, which would make it easy to refer to in short form.

Another question to be answered: what to do when standard extensions
are specified that aren't included in that given -misa-spec (but the
compiler does indeed know about)? Error, or use the first released
version? This interacts with the question below about what default
-misa-spec is assumed (unless we imagine different behaviour depending
on explicitly specified or compile-time assumed misa-spec).

> - Limit the version of ISA extensions?
> - e.g. You can't use -march=rv32i2p1 -misa-spec=2.2 since it
> require -misa-spec=201906

I think allowing -march to override might be reasonable behaviour.

> - Add one field on ELF attribute, new integer field
> - Value 20/21/22 for 2.0/2.1/2.2
> - Value YYYYMMDD for later version, e.g. 20190608 for
> 20190608-Base-Ratified.

Would it be better to just produce a canonicalised ISA naming string
with all version information and emit that?

> 2. Default implied Zicsr and Zifencei:
> - Minimized the impact of behavior change for most use case.
> - Let compiler/assembler append Zicsr and Zifencei automatically,
> because this configuration is most general.
> - New compiler/assembler option: -m[no-]implied-zicsr-zifencei
> - New configuration option for building GNU toolchain:
> --with-implied-zicsr-zifencei=[yes|no]

I agree that Zicsr is likely to cause plenty of confusion. I m
concerned that adding another way of controlling that behaviour beyond
-misa-spec is just going to lead to prolonged confusion. e.g. people
confused why different toolchains that seem otherwise identical have
different behaviour. Is setting the default -misa-spec at compile time
not enough? For people who don't want to move to the new zicsr
behaviour, they can stick to an older -misa-spec.

> 3. Discard old order for x, s, sx.
> - We didn't have any s extension yet, so just using new order in toolchain
>
> 4. How to expanding version of G?
> - G2.2 = I2p2_M2p2_A2p2_F2p2_D2p2 ?
> - G2.2 = I2p0_M2p0_A2p0_F2p0_D2p0 ?
> - Or other expanding scheme?

Versioning for G seems too confusing given that it never really had a
version other than the doc version, so I suggest just relying on
misa-spec for this.

> ----------------- GNU Toolchain only -----------------
>
> 5. Add new configure options for building toolchain:
> - --with-riscv-isa-spec= to control the default ISA spec version in toolchain,
> - --with-riscv-isa-version=<isa-with-versions> to provide a way fine
> tune the default version of each ISA extension.
> - --with-implied-zicsr-zifencei=[yes|no] to control
> -mimplied-zicsr-zifencei enable by default or not.

As mentioned previously in this response, the implied zicsr-zifencei
feels like it might cause more confusion than it solves.

Best,

Alex

[Kito Cheng]

Hi Alex:

> Another question to be answered: what to do when standard extensions
> are specified that aren't included in that given -misa-spec (but the
> compiler does indeed know about)? Error, or use the first released
> version?

Yeah, that's gray zone, so I plan to introduce --with-riscv-isa-version= option
to configure the default version of extensions,

but here is still gray zone here, the version might not specified in
ISA spec/--with-riscv-isa-version=, I think we have two options here:

- set to first released version and set to 0p0 if compiler/assembler
didn't know anything.
- set to latest released version and set to 0p0 if compiler/assembler
didn't know anything.

I prefer set latest released version here.

> This interacts with the question below about what default
> -misa-spec is assumed (unless we imagine different behaviour depending
> on explicitly specified or compile-time assumed misa-spec).

For GNU toolchain, there would be a configure time option to control the default
value of -misa-spec=, and set to latest spec by default if not given.

>> - Add one field on ELF attribute, new integer field
>> - Value 20/21/22 for 2.0/2.1/2.2
>> - Value YYYYMMDD for later version, e.g. 20190608 for
>> 20190608-Base-Ratified.
> Would it be better to just produce a canonicalised ISA naming string
> with all version information and emit that?

The original idea was control the parsing order, but the original
reason seems gone,
because seems we all agree old parsing order can be discard.

> I agree that Zicsr is likely to cause plenty of confusion. I m
> concerned that adding another way of controlling that behaviour beyond
> -misa-spec is just going to lead to prolonged confusion. e.g. people
> confused why different toolchains that seem otherwise identical have
> different behaviour. Is setting the default -misa-spec at compile time
> not enough? For people who don't want to move to the new zicsr
> behaviour, they can stick to an older -misa-spec.

Sound reasonable, -misa-spec should be enough.

> Versioning for G seems too confusing given that it never really had a
> version other than the doc version, so I suggest just relying on
> misa-spec for this.

Yeah, agree, the only thing we might need to case is g2p0/g2,
Jacob has proposal accept that for backward compatibility in isa-dev,
since it mentioned in ISA spec before.


So summarize the items reached consensus here.

1. -misa-spec=[2.0|2.1|2.2|YYYYMM|YYYYMMDD]

2. Discard old order for x, s, sx.
3. G without version.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2BwH297xRLbDQv7LeQ-DXBFg6K37QVVQfBOYzrXz5mFs7ZrMjw%40mail.gmail.com.