1. Messages
  2. Disabling and re-enabling extensions

Re: Disabling and re-enabling extensions

Allen Baum
 

(Compliance hat on):
  I'd like to dig into that a bit further. This has come up in the context of WARL registers, where changing the value of some CSR field1 causes some other CSR field2 value to become illegal, and therefore reading/applying that CSR field2 will then reflect a different, now legal value. 
The question becomes: if CSR field1 is restored to its previous value (or some other value where the original CSR field2 was legal): does CSR field2 revert to that original value, or does it keep the newer (presumably legal) value?

Another way to look at this is: is it required that the illegal->legal mapping occur only when reading/using the CSR (by HW or SW), or that the result of an mapping force the field to be written (either explicitly on a write, or when changed while writing some other field)?

(Compliance hat going back into its closet)

On Wed, Sep 9, 2020 at 12:14 PM Paul Donahue <pdonahue@...> wrote:

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
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.