You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 7, 2024. It is now read-only.
Initially, the following bits are defined in mstateen0, hstateen0, and sstateen0:
bit 0 - Custom state
bit 1 - fcsr for Zfinx and related extensions (Zdinx, etc.)
Bit 0 controls access to any and all custom state.
Does it means stateen won't reserve some bits for custom extensions, and the custom extensions should have their own enablement mechanisms? If the spaces in stateen are not critical (have room for custom extension), is it possible for the standard open some bits for custom use alike upper 16-bit of mip?
It's a little painful that some custom extensions can be granted to user mode, and others can not be granted. If they all share the same switch, the hardware couldn't distinguish whether the extension can be used by user mode.
Thanks!
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Current spec has following description:
Does it means stateen won't reserve some bits for custom extensions, and the custom extensions should have their own enablement mechanisms? If the spaces in stateen are not critical (have room for custom extension), is it possible for the standard open some bits for custom use alike upper 16-bit of
mip
?It's a little painful that some custom extensions can be granted to user mode, and others can not be granted. If they all share the same switch, the hardware couldn't distinguish whether the extension can be used by user mode.
Thanks!
The text was updated successfully, but these errors were encountered: