You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mndstrmr points out in microsoft/cheriot-ibex#30 that the sail behaves incorrectly in cases where registers greater than 15 (which are not valid in RV32E) are used in instructions that have side-effects other than writing the destination register such as CSRRW.
This is due to the way that we use a Sail exception in the register read / write functions to detect the invalid register rather than detecting it during decode.
This was for expedience i.e. to avoid many changes to the upstream sail-riscv repo.
It would be best if the upstream had support for RV32E. In fact we could do with clarification of the RISC-V specification as there are two reasonable interpretations at the moment:
raise a reserved instruction exception (i.e. fail at decode stage)
ignore the top bit of the register fields
We are attempting to implement 1. and Ibex used to do 2. 2 is easier to implement but probably less useful.
The text was updated successfully, but these errors were encountered:
riscv/sail-riscv#523 filed upstream. I looked again at the latest RISC-V spec and it does say that the unused encodings are reserved i.e. should cause a reserved instruction exception.
@mndstrmr points out in microsoft/cheriot-ibex#30 that the sail behaves incorrectly in cases where registers greater than 15 (which are not valid in RV32E) are used in instructions that have side-effects other than writing the destination register such as
CSRRW
.This is due to the way that we use a Sail exception in the register read / write functions to detect the invalid register rather than detecting it during decode.
This was for expedience i.e. to avoid many changes to the upstream
sail-riscv
repo.It would be best if the upstream had support for RV32E. In fact we could do with clarification of the RISC-V specification as there are two reasonable interpretations at the moment:
We are attempting to implement 1. and Ibex used to do 2. 2 is easier to implement but probably less useful.
The text was updated successfully, but these errors were encountered: