RV32IM with Intel APX

[nazar-pc]

APX will add 16 more general purpose registers, making it possible to map RV32I, not just RV32E to native registers (this is my understanding of the decision behind RV32E choice). From what I understand, AMD already reserved them as well.

So essentially fewer registers on x86-64 is a temporary situation and maybe using RV32I is acceptable.

P.S. I do not know how big of a departure would it be to use more registers implementation-wise and what performance implications of that might be for current or future processors, just wanted to share this in case it is useful.

P.P.S. I thought of RV32I because https://github.com/risc0/risc0 supports RV32IM, but I guess RV32EM code might still run there just fine and will be forward-compatible with RV32IM "host".

[koute]

Yes, I know about the APX. (:

Unfortunately it's going to take at least a decade before it's widespread enough, so it's not really an option right now. Once it's widely available we could always consider it in the future for a v2 of the VM.

[nazar-pc]

My knowledge of this stuff is very limited, but will something compiled for RV32E run on RV32I? I'm thinking about generating a proof of execution of future RISC-V-based Substrate runtime in RISC Zero VM.

[koute]

My knowledge of this stuff is very limited, but will something compiled for RV32E run on RV32I?

There's more to it than the instruction set (e.g. the ABI, the used RISC-V extensions, etc.) so you would have to recompile anyway, but in general yes.

[nazar-pc]

Well, my understanding on the high level was that the major difference between RV32EM and RV32IM specifically is reduced number of general purpose registers in the former. The goal would definitely be to use the same ELF binary without recompilation.

[koute]

You cannot use the same ELF file across different VMs even if the instruction set will be the same, at the very least because different VMs will have different ways of communicating with the external world.