.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