In a belated followup to https://github.com/riscv/riscv-isa-manual/issues/332#issuecomment-466581845, I have the same question as John Hauser.  One thing that has changed is that now the architecture has an explicit goal of either describing behavior or using the term UNSPECIFIED.

To restate the question: Various extensions that add architectural state can be enabled/disabled via misa.  What happens to that architectural state if the extension is disabled and later re-enabled?

In particular, what happens to the following state if the associated misa bit is cleared and then set:

• misa.F: FP registers and fcsr

• misa.D: upper part of FP registers (when misa.D=0 and misa.F=1)

• misa.Q: upper part of FP registers (when misa.Q=0 and misa.F=1)

• misa.S: supervisor CSR state

• misa.H: hypervisor CSR state

• misa.V: vector state

The spec is clear about the treatment of mepc[1] and sepc[1] when misa.C is disabled and subsequently re-enabled.  That bit will contain the last written value even if the write comes while C is disabled.

In a different approach, the spec is also clear that if mstatus.FS is set to Off that the FP state is preserved.  However, this S-mode operation is different from the M-mode misa.F control.  And the question remains about disabling portions of the FP registers where implementations may continue to do single-precision operations that write (at least) the lower part of the register.

Implementations that support H are encouraged to make misa.H writable.  While support for disabling D without disabling F is potentially academic, most implementations are expected to allow software to disable and re-enable H.

I propose that there should be a sentence in the misa description that says that, unless otherwise specified, when software enables an extension that was previously disabled then all state uniquely associated with that extension is UNSPECIFIED.

Thanks,

-Paul