Date
1 - 10 of 10
[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
|
|
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 :
|
|
toggle quoted messageShow quoted text
On Thu, Aug 26, 2021 at 5:46 AM Mark Himelstein <markhimelstein@...> wrote:
|
|
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:
|
|
Kito Cheng
Hi Mark:
It sounds like we can expect all privilege stuff like machine-levelall the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk. 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:
toggle quoted messageShow quoted text
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:
|
|
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.
|
|
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 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
|
|
Yes, that was the plan,
Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote:On Fri, 27 Aug 2021 13:37:13 -0700, "Greg Favor" <gfavor@...> said: | 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 vectorYes, that's the consensus of the RISC-V LLVM/GNU community :)
|
|