|
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
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
toggle quoted message
Show quoted text
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
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).
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
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
|
|
|
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.
|
|
|
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.
toggle quoted message
Show quoted text
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
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.
|
|
|
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 |
|
|
|
| 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 :)
|
|
|
