No functional change.
It's safe to use the virtualized sstatus here after [this
bugfix](https://github.com/riscv/riscv-isa-sim/pull/680) since the
value of hsie doesn't matter if state.v==1. In the cases where it does
matter (i.e. when state.v==0), hsie will come from sstatus, not
vsstatus.
Before that bugfix, this needed to use sstatus (not vsstatus) always,
because sstatus.sie was considered when in either HS-mode or VS-mode.
This changes the commitlog of `csrw sie` so that it only logs a change
to `mie`, instead of both `mie` and `sie`. This is arguably
preferable, since there is no real `sie` register -- it is only a view
into `mie`.
It also adds proper tracing of the modification to `mie` when doing
`csrw` to `hie` and `vsie`, which were both missing previously.
This changes the commitlog of `csrw sip` so that it only logs a change
to `mip`, instead of both `mip` and `sip`. This is arguably
preferable, since there is no real `sip` register -- it is only a view
into `mip`.
It also adds proper tracing of the modification to `mip` when doing
`csrw` to `hip`, `hvip`, and `vsip`, which were all missing
previously.
To reduce repetition in code.
This has one functional effect that I can see: before this change, on
a config that supports floating point but not S-mode or Vector,
writing misa.F=0 would freeze the FS bits in mstatus. I assume this
was an accident and never the intended behavior, though I can't find
anything in the privileged spec about this.
Now the FS bits will always be writable regardless of misa.F, if the
bits exist at all. (Because we now call extension_enabled('F') only
once, at reset, instead of every mstatus write.)
This has no functional effect today, since vsstatus always has all
these bits (since Hypervisor requires so many of these other optional
features), and sstatus_proxy writes through mstatus, which already
considers all these options.
This change will enable me to share this sstatus mask within mstatus
soon.
Scott Johnson