1. Topics
  2. [RFC] Toolchain interface for privilege spec related stuff.

[RFC] Toolchain interface for privilege spec related stuff.

Kito Cheng
 

Hi :

I am Kito Cheng, one of the RISC-V open source toolchain developer.
Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing
how to version control the privilege spec stuff - which CSR and
instruction defined in privilege spec can be used.

The reason why we want an option control is the backward
compatibility, as we know privileges spec (unfortunately) has few
incompatible changes like sfence.vm is replaced by sfence.vma, hret is
removed, and several minor incompatible changes.

Current proposal is add a new command line option `-mpriv-spec=` to
control the version of privilege spec, it can be -mpriv-spec=1.9,
-mpriv-spec=1.10 or -mpriv-spec=1.11, and add -mpriv-spec=1.12 once
priv spec 1.12 ratified.

That will imply the version of machine-level ISA, supervisor ISA, and
maybe hypervisor extension if there is no ISA string allocated.

So there would be two command line interfaces for all privilege spec,

-march=: use -march to control if the extension has ISA string like
Svinval, that need to enabled by -march option like
-march=rv32i_svinval,

-mpriv-spec=: Other privilege stuffs are controlled by
`-mpriv-spec=` and their will having a default value in the toolchain,
the default value might different on different versions of the
toolchain.


Is it a reasonable interface to current privilege spec? or any comment
or suggestion on this proposal?

[1] https://github.com/riscv/riscv-toolchain-conventions/pull/16
mark
 

all the specs will have unique extension names. it is also possible to have rollup extension names like we have for  crypto like Zk.

I suggest we make the options match the extension names and if needed request a roll up extension name.

ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.

mark

On Thu, Aug 26, 2021, 1:27 AM Kito Cheng <kito.cheng@...> wrote:
Hi :

I am Kito Cheng, one of the RISC-V open source toolchain developer.
Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing
how to version control the privilege spec stuff - which CSR and
instruction defined in privilege spec can be used.

The reason why we want an option control is the backward
compatibility, as we know privileges spec (unfortunately) has few
incompatible changes like sfence.vm is replaced by sfence.vma, hret is
removed, and several minor incompatible changes.

Current proposal is add a new command line option `-mpriv-spec=` to
control the version of privilege spec, it can be -mpriv-spec=1.9,
-mpriv-spec=1.10 or -mpriv-spec=1.11, and add  -mpriv-spec=1.12 once
priv spec 1.12 ratified.

That will imply the version of machine-level ISA, supervisor ISA, and
maybe hypervisor extension if there is no ISA string allocated.

So there would be two command line interfaces for all privilege spec,

   -march=: use -march to control if the extension has ISA string like
Svinval, that need to enabled by -march option like
-march=rv32i_svinval,

    -mpriv-spec=: Other privilege stuffs are controlled by
`-mpriv-spec=` and their will having a default value in the toolchain,
the default value might different on different versions of the
toolchain.


Is it a reasonable interface to current privilege spec? or any comment
or suggestion on this proposal?

[1] https://github.com/riscv/riscv-toolchain-conventions/pull/16
mark
 


On Thu, Aug 26, 2021 at 5:46 AM Mark Himelstein <markhimelstein@...> wrote:
all the specs will have unique extension names. it is also possible to have rollup extension names like we have for  crypto like Zk.

I suggest we make the options match the extension names and if needed request a roll up extension name.

ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.

mark

On Thu, Aug 26, 2021, 1:27 AM Kito Cheng <kito.cheng@...> wrote:
Hi :

I am Kito Cheng, one of the RISC-V open source toolchain developer.
Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing
how to version control the privilege spec stuff - which CSR and
instruction defined in privilege spec can be used.

The reason why we want an option control is the backward
compatibility, as we know privileges spec (unfortunately) has few
incompatible changes like sfence.vm is replaced by sfence.vma, hret is
removed, and several minor incompatible changes.

Current proposal is add a new command line option `-mpriv-spec=` to
control the version of privilege spec, it can be -mpriv-spec=1.9,
-mpriv-spec=1.10 or -mpriv-spec=1.11, and add  -mpriv-spec=1.12 once
priv spec 1.12 ratified.

That will imply the version of machine-level ISA, supervisor ISA, and
maybe hypervisor extension if there is no ISA string allocated.

So there would be two command line interfaces for all privilege spec,

   -march=: use -march to control if the extension has ISA string like
Svinval, that need to enabled by -march option like
-march=rv32i_svinval,

    -mpriv-spec=: Other privilege stuffs are controlled by
`-mpriv-spec=` and their will having a default value in the toolchain,
the default value might different on different versions of the
toolchain.


Is it a reasonable interface to current privilege spec? or any comment
or suggestion on this proposal?

[1] https://github.com/riscv/riscv-toolchain-conventions/pull/16
Allen Baum
 

.Note that the Imperas OVPsim simulator, and the tests they've written for it, can already specify priv spec version numbers  (and vector spec version numbers).


On Thu, Aug 26, 2021 at 7:52 AM mark <markhimelstein@...> wrote:

On Thu, Aug 26, 2021 at 5:46 AM Mark Himelstein <markhimelstein@...> wrote:
all the specs will have unique extension names. it is also possible to have rollup extension names like we have for  crypto like Zk.

I suggest we make the options match the extension names and if needed request a roll up extension name.

ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.

mark

On Thu, Aug 26, 2021, 1:27 AM Kito Cheng <kito.cheng@...> wrote:
Hi :

I am Kito Cheng, one of the RISC-V open source toolchain developer.
Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing
how to version control the privilege spec stuff - which CSR and
instruction defined in privilege spec can be used.

The reason why we want an option control is the backward
compatibility, as we know privileges spec (unfortunately) has few
incompatible changes like sfence.vm is replaced by sfence.vma, hret is
removed, and several minor incompatible changes.

Current proposal is add a new command line option `-mpriv-spec=` to
control the version of privilege spec, it can be -mpriv-spec=1.9,
-mpriv-spec=1.10 or -mpriv-spec=1.11, and add  -mpriv-spec=1.12 once
priv spec 1.12 ratified.

That will imply the version of machine-level ISA, supervisor ISA, and
maybe hypervisor extension if there is no ISA string allocated.

So there would be two command line interfaces for all privilege spec,

   -march=: use -march to control if the extension has ISA string like
Svinval, that need to enabled by -march option like
-march=rv32i_svinval,

    -mpriv-spec=: Other privilege stuffs are controlled by
`-mpriv-spec=` and their will having a default value in the toolchain,
the default value might different on different versions of the
toolchain.


Is it a reasonable interface to current privilege spec? or any comment
or suggestion on this proposal?

[1] https://github.com/riscv/riscv-toolchain-conventions/pull/16
Kito Cheng
 

Hi Mark:

all the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk.

I suggest we make the options match the extension names and if needed request a roll up extension name.

ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.
It sounds like we can expect all privilege stuff like machine-level
ISA, supervisor ISA will become several extensions at privilege spec
1.12,
and then those extensions can be controlled by profile and arch string.

For native compilation, I suppose there is no doubt we should use the
discover mechanism for that.
For cross compilation, ideally it can be covered by profile, but I am
concerned about backward compatibility,
existing RISC-V platforms are still using older privilege spec (<=
1.12), and didn't have the concept of profile yet,
so I think we should have an option for those users.

I guess this option might become less useful when we all transfer to
the world with the profile, but still useful
when we cross compile for the older RISC-V platform.
Kito Cheng
 

Hi Allen:

Thanks for the information :)

For non-priverage extension, toolchain can control version for each
extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector
extension with version 0.10.

On Fri, Aug 27, 2021 at 8:38 AM Allen Baum <allen.baum@...> wrote:

.Note that the Imperas OVPsim simulator, and the tests they've written for it, can already specify priv spec version numbers (and vector spec version numbers).


On Thu, Aug 26, 2021 at 7:52 AM mark <markhimelstein@...> wrote:

+Philipp Tomsich

On Thu, Aug 26, 2021 at 5:46 AM Mark Himelstein <markhimelstein@...> wrote:

all the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk.

I suggest we make the options match the extension names and if needed request a roll up extension name.

ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.

mark

On Thu, Aug 26, 2021, 1:27 AM Kito Cheng <kito.cheng@...> wrote:

Hi :

I am Kito Cheng, one of the RISC-V open source toolchain developer.
Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing
how to version control the privilege spec stuff - which CSR and
instruction defined in privilege spec can be used.

The reason why we want an option control is the backward
compatibility, as we know privileges spec (unfortunately) has few
incompatible changes like sfence.vm is replaced by sfence.vma, hret is
removed, and several minor incompatible changes.

Current proposal is add a new command line option `-mpriv-spec=` to
control the version of privilege spec, it can be -mpriv-spec=1.9,
-mpriv-spec=1.10 or -mpriv-spec=1.11, and add -mpriv-spec=1.12 once
priv spec 1.12 ratified.

That will imply the version of machine-level ISA, supervisor ISA, and
maybe hypervisor extension if there is no ISA string allocated.

So there would be two command line interfaces for all privilege spec,

-march=: use -march to control if the extension has ISA string like
Svinval, that need to enabled by -march option like
-march=rv32i_svinval,

-mpriv-spec=: Other privilege stuffs are controlled by
`-mpriv-spec=` and their will having a default value in the toolchain,
the default value might different on different versions of the
toolchain.


Is it a reasonable interface to current privilege spec? or any comment
or suggestion on this proposal?

[1] https://github.com/riscv/riscv-toolchain-conventions/pull/16
mark
 

it sounds like we are aligned

On Aug 26, 2021, at 8:27 PM, Kito Cheng <kito.cheng@...> wrote:

Hi Mark:

 all the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk.

 I suggest we make the options match the extension names and if needed request a roll up extension name.

 ultimately we'd like users to use the profile names to select the whole set we know work together coupled with discovery as appropriate for native compiles. cross compiles will need more arguments if the target is different than the source system.

It sounds like we can expect all privilege stuff like machine-level
ISA, supervisor ISA will become several extensions at privilege spec
1.12,
and then those extensions can be controlled by profile and arch string.

For native compilation, I suppose there is no doubt we should use the
discover mechanism for that.
For cross compilation, ideally it can be covered by profile, but I am
concerned about backward compatibility,
existing RISC-V platforms are still using older privilege spec (<=
1.12), and didn't have the concept of profile yet,
so I think we should have an option for those users.

I guess this option might become less useful when we all transfer to
the world with the profile, but still useful
when we cross compile for the older RISC-V platform.
Greg Favor
 

On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote:
For non-priverage extension, toolchain can control version for each
extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector
extension with version 0.10.

Should I assume that for the ratified vector spec simply 'v' can be specified?  And that a version number is only needed to refer to a pre-ratified version of the vector spec?

Greg
Krste Asanovic
 

Yes, that was the plan,
Krste

On Fri, 27 Aug 2021 13:37:13 -0700, "Greg Favor" <gfavor@...> said:
| On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote:
| For non-priverage extension, toolchain can control version for each
| extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector
| extension with version 0.10.

| Should I assume that for the ratified vector spec simply 'v' can be specified?  And that a version number is only needed to refer to a pre-ratified version of the vector
| spec?

| Greg

|
Kito Cheng
 

| Should I assume that for the ratified vector spec simply 'v' can be specified? And that a version number is only needed to refer to a pre-ratified version of the vector
| spec?
Yes, that's the consensus of the RISC-V LLVM/GNU community :)
1 - 10 of 10