Clarification on mstatus.fs/xs

[dharan G]

Hi all,

In the table 3.4: FS and XS state transitions in page 26 of RISC-V Privileged spec v1.10, it is mentioned that there is a way to use instructions to disable (FP) extension unit and to unconfigure (FP) extension unit. Could someone explain about the difference in these instructions and its effects on (FP) extension unit. 

Thanks in Advance,

G.Dharani Shankar.

[Greg Favor]

On Wed, Dec 8, 2021 at 2:38 AM dharan G <dhara...@gmail.com> wrote:

Hi all,

In the table 3.4: FS and XS state transitions in page 26 of RISC-V Privileged spec v1.10, it is mentioned that there is a way to use instructions to disable (FP) extension unit and to unconfigure (FP) extension unit. Could someone explain about the difference in these instructions and its effects on (FP) extension unit. 

The table header says "Note that the standard floating-point and vector extensions do not support user-mode unconfigure or disable/enable instructions."

Also, a key word is the "user-mode" qualification.  For FP extensions machine-mode can use misa F, D, and Q bits (if they are implemented as writeable) to disable the associated extensions.  But in any case there is no concept of "configure/unconfigure" for the FP extensions. 

Greg

 

[Allen Baum]

I will take a not-so-wild, but NOT authoritative guess.

Disabled is when the configuration is set such that any attempt to execute an FP op will trap with an illegal op exception.

There could be two reasons for that: misa.F is sero, or mstatus.FS=00. 

      (Since I know I will be corrected on this,  let me state that, yes, I know if misa.F=0, 

      there is no guarantee that an attempt to execute an op with an FP encoding will trap

      even if the FP unit is present and misa.F is a read/write bit)

Unconfigured is simply an indication to the OS that the register state doesn't need to be saved, but may need to be restored or initialized.

Section 3.1.6.6 should be read closely, but it does explain this.

On Wed, Dec 8, 2021 at 2:38 AM dharan G <dhara...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/efacfcc4-5c62-4a46-82c5-d6e37fd3ed31n%40groups.riscv.org.

[dharan G]

Thank you for replying.

In page 25 of RISC-V Privileged spec v1.10, it is mentioned that,

1)"If the status is Initial, the context must be set to an initial constant value on context restore to avoid a security hole, but this can be done without accessing memory. For example, the floating-point registers can all be initialized to the immediate value 0."

2)"Changing the setting of FS has no effect on the contents of the floating-point register state. In particular, setting FS=Off does not destroy the state, nor does setting FS=Initial clear the contents."

From the above lines, does it imply that when MSTATUS.FS is set to Initial state(01), the implementation will not initialize the FP state, rather privileged code has to initialize them?

Thanks in advance,
Dharani Shankar   

[Allen Baum]

That is certainly my interpretation.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/cbb2bf46-9b43-47ca-90ef-b90eb8958245n%40groups.riscv.org.

[Andrew Waterman]

Yeah, that's indeed what we meant by "nor does setting FS=Initial clear the contents".

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DA_OTcvHGKMobokOrcTqKDCHRQxQ16Khd_L%2B2QVHJK0jg%40mail.gmail.com.