RISC-V core ISA versions

[Chongfeng Hu]

Hello,

Machine ISA v1.11 got Ratified status, but now there's Machine ISA v1.12 Ratified, with updates. How do I interpret this? Will future ISA versions potentially introduce new behaviors and break software compatibility? What does "ratified" actually mean to software developers?

Also, given an arbitrary RISC-V core, is there an instruction to find out which ISA versions (both unprivileged & privileged) it complies to?

Regards,

Chongfeng Hu

[Palmer Dabbelt]

On Wed, Oct 26, 2022, 11:27 PM Chongfeng Hu <chongf...@gmail.com> wrote:

Hello,

Machine ISA v1.11 got Ratified status, but now there's Machine ISA v1.12 Ratified, with updates. How do I interpret this? Will future ISA versions potentially introduce new behaviors and break software compatibility?

It's hard to predict the future, but historically there have been regular changes to the PDFs that break software.  IIUC that's subtly different from saying the specifications have changed in a way that breaks software, but most people don't seem to differentiate between the two.  In practice people read and implement those PDFs, so we've just got to live with the fallout of those changes in order to make software that runs on the HW.

What does "ratified" actually mean to software developers?

There's a lot of software developers so I'm not sure there's going to be a single answer to that.

Also, given an arbitrary RISC-V core, is there an instruction to find out which ISA versions (both unprivileged & privileged) it complies to?

There's m{arch,imp,vendor}id to tell you what the implementation is, but that relies on vendors doing something sane so it's likely to be hit and miss.  We're doing that in Linux now, though, so at least there should be some incentive for vendors to make it work.

Regards,

Chongfeng Hu

--
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/a9d6e9cd-6b87-4b87-b6f8-cc7b5b2bec3fn%40groups.riscv.org.

[Chongfeng Hu]

On Thu, Oct 27, 2022 at 1:49 PM Palmer Dabbelt <pal...@dabbelt.com> wrote:

On Wed, Oct 26, 2022, 11:27 PM Chongfeng Hu <chongf...@gmail.com> wrote:

Hello,

Machine ISA v1.11 got Ratified status, but now there's Machine ISA v1.12 Ratified, with updates. How do I interpret this? Will future ISA versions potentially introduce new behaviors and break software compatibility?

It's hard to predict the future, but historically there have been regular changes to the PDFs that break software.  IIUC that's subtly different from saying the specifications have changed in a way that breaks software, but most people don't seem to differentiate between the two.  In practice people read and implement those PDFs, so we've just got to live with the fallout of those changes in order to make software that runs on the HW.

What does "ratified" actually mean to software developers?

There's a lot of software developers so I'm not sure there's going to be a single answer to that.

To be specific, I'm talking about OS developers. Imagine 10 years later, we have machine ISA V1.11, 1.12, 1.13 ... 1.20, all marked as ratified. In the best case scenario, each version is backward compatible, but still introduces new behaviors & features. There's a mix of chips on the market implementing different ISA versions. If there's not a reliable way for the OS to programmatically tell which ISA version the chip supports, OS developers will be forced to use only a common denominator feature set (which is the lowest version, V1.11), while not be able to leverage the latest & greatest features, because if so then all older chips will fail. But then what's the point of introducing new versions?

One example is the SFENCE.VM instruction. It was defined in V1.9.1, but later removed in favor of SFENCE.VMA in V1.10. How is an OS able to support both versions of ISA while not knowing which version the chip complies to?

Or am I wrongly assuming that RISC-V is meant for general computing, while in reality it's only focusing on embedded scenarios?

[Palmer Dabbelt]

On Thu, Oct 27, 2022 at 3:21 PM Chongfeng Hu <chongf...@gmail.com> wrote:

On Thu, Oct 27, 2022 at 1:49 PM Palmer Dabbelt <pal...@dabbelt.com> wrote:

On Wed, Oct 26, 2022, 11:27 PM Chongfeng Hu <chongf...@gmail.com> wrote:

Hello,

Machine ISA v1.11 got Ratified status, but now there's Machine ISA v1.12 Ratified, with updates. How do I interpret this? Will future ISA versions potentially introduce new behaviors and break software compatibility?

It's hard to predict the future, but historically there have been regular changes to the PDFs that break software.  IIUC that's subtly different from saying the specifications have changed in a way that breaks software, but most people don't seem to differentiate between the two.  In practice people read and implement those PDFs, so we've just got to live with the fallout of those changes in order to make software that runs on the HW.

What does "ratified" actually mean to software developers?

There's a lot of software developers so I'm not sure there's going to be a single answer to that.

To be specific, I'm talking about OS developers. Imagine 10 years later, we have machine ISA V1.11, 1.12, 1.13 ... 1.20, all marked as ratified. In the best case scenario, each version is backward compatible, but still introduces new behaviors & features. There's a mix of chips on the market implementing different ISA versions. If there's not a reliable way for the OS to programmatically tell which ISA version the chip supports, OS developers will be forced to use only a common denominator feature set (which is the lowest version, V1.11), while not be able to leverage the latest & greatest features, because if so then all older chips will fail. But then what's the point of introducing new versions?

Well, there's a lot of OS developers too :).  The problems you describe are pretty reasonable and there's no real fix for them, it's just a matter of trying to detect each feature in an ad-hoc fashion and then make it function acceptably.  It's certainly a lot of work, but I think we've managed to do it acceptably so far -- with the latest round of extensions that's starting to be less true, but folks are working on dealing with it.

 

One example is the SFENCE.VM instruction. It was defined in V1.9.1, but later removed in favor of SFENCE.VMA in V1.10. How is an OS able to support both versions of ISA while not knowing which version the chip complies to?

We happen to have set the baseline to 1.10 in Linux so we don't have that specific problem, but broadly speaking it's similar to a bunch of other stuff we do in the kernel where we try to detect stuff and then JIT it.

 

Or am I wrongly assuming that RISC-V is meant for general computing, while in reality it's only focusing on embedded scenarios?

RISC-V is meant for everything, but if by "general computing" you mean binary-compatible distributions then we have a long way to go before things are sane.

[Nick Knight]

Regarding the versioning of the supervisor-level ISA, if I were an OS developer (and I'm not), I would only target the standard profiles: https://github.com/riscv/riscv-profiles/releases/download/v0.8/profiles.pdf

RVA20S64: requires Ss1p11

RVA22S64: requires Ss1p12

I expect my newer OS releases would stop supporting older profiles, after a period of time.

If a user wants a newer release supported on an older profile, or on a machine that doesn't implement one of these profiles, then they'd have to pay for support, fork the project, etc.

Regarding the versioning of the machine-level ISA, I'm hoping to be insulated from that by the SBI, e.g., https://github.com/riscv-software-src/opensbi

Regarding runtime discovery of ISA features, I'm hoping that will eventually be resolved by Unified Discovery, https://lists.riscv.org/g/tech-config

Best,

Nick Knight

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

[Palmer Dabbelt]

On Thu, Oct 27, 2022 at 4:25 PM Nick Knight <nick....@sifive.com> wrote:

Regarding the versioning of the supervisor-level ISA, if I were an OS developer (and I'm not), I would only target the standard profiles: https://github.com/riscv/riscv-profiles/releases/download/v0.8/profiles.pdf

RVA20S64: requires Ss1p11

RVA22S64: requires Ss1p12

Unfortunately that doesn't really fix the problem: vendors self-certify their implementations, so these sorts of requirements don't really carry any meaning when it comes to making real software run.  In practice software supports the hardware that users care about, the profiles don't change anything there.

 

I expect my newer OS releases would stop supporting older profiles, after a period of time.

If a user wants a newer release supported on an older profile, or on a machine that doesn't implement one of these profiles, then they'd have to pay for support, fork the project, etc.

Once something is supported it takes a long time to drop it.  Just look at the discussions around Linux considering dropping support for the i486, which is 33 years old.  If we follow those timelines then even the Unleashed will be supported until I'm supposed to retire, which is de facto forever.  That seems pretty crazy, but tossing support for hardware that's incompatible with a specification that was frozen two days ago seems crazier.

There's a pretty big support gap between 2 days and 33 years so it'll remain to be seen what actually happens in RISC-V land, but I doubt we're going to be all that different from anyone else here.

 

Regarding the versioning of the machine-level ISA, I'm hoping to be insulated from that by the SBI, e.g., https://github.com/riscv-software-src/opensbi

In practice that also doesn't really fix the problem, it just adds another specification (with another set of release timelines and implementations) that we have to handle compatibility with.

 

Regarding runtime discovery of ISA features, I'm hoping that will eventually be resolved by Unified Discovery, https://lists.riscv.org/g/tech-config

That also doesn't really fix anything: we've already got ACPI and DT that we have to live with, adding a third standard just compounds the problem.