Skip to content
This repository has been archived by the owner on Mar 7, 2024. It is now read-only.

Clarify traps when Zfinx implemented #6

Open
JamesKenneyImperas opened this issue Jan 5, 2022 · 0 comments
Open

Clarify traps when Zfinx implemented #6

JamesKenneyImperas opened this issue Jan 5, 2022 · 0 comments

Comments

@JamesKenneyImperas
Copy link

When Hypervisor, Zfinx and Smstateen are all implemented, can you please clarify which trap occurs when attempting to execute a floating point instruction in VS mode when mstateen0[1]=1 and hstateen0[1]=0?

If floating point is implemented and Zfinx is not implemented, floating point would be enabled by sstatus.FS and vsstatus.FS. Section 8.2.1 of the Privileged Specification says that in this case:

When V=1, both vsstatus.FS and the HS-level sstatus.FS are in effect. Attempts to execute a floating-point instruction when either field is 0 (Off) raise an illegal-instruction exception.

However, the Smstateen specification has this statement:

The stateen registers at each level control access to state at all less-privileged levels, but not at its own level. This is analogous to how the existing counteren CSRs control access to performance counter registers. Just as with the counteren CSRs, when a stateen CSR prevents access to state by less-privileged levels, an attempt in one of those privilege modes to execute an instruction that would read or write the protected state raises an illegal instruction exception, or, if executing in VS or VU mode and the circumstances for a virtual instruction exception apply, raises a virtual instruction exception instead of an illegal instruction exception.

Is it expected that an Illegal Instruction exception would be generated (following the first precedent) or a Virtual Instruction exception (following the precedent of CSR accesses enabled by Smstateen CSRs)?

Thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant