Re: Disabling and re-enabling extensions


Is there a checklist of requirements for priv specifications?

if not should there be?

If there is, would this be a requirement in that list to specify to some level of clarity (maybe indicating what is allowed to be left unspecified or not for example) what happens when the extension is turned off and on. and maybe provide overall guidance for future extensions.  I suggest it might be best not to just leave this up to reviews to catch these in an ad hoc manner.

Paul brought a broader set of items to light which makes me want to ask that once we answer paul and john's questions are there any others lurking out there from the past or in flight? Do we need to do a little audit?

am I misunderstanding something?


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

In a belated followup to, 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.



Join to automatically receive all group messages.