-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mstatus cleanup #683
base: master
Are you sure you want to change the base?
mstatus cleanup #683
Conversation
`architecture` means XLEN (not `xlen`, which means MXLEN) and XLEN is always defined. Returning None means Sail made an error somewhere and there is no reason to poison unrelated code with it. Remove the option type from architecture and implement architecture as mapping. Incorrect usage will throw runtime mapping error. Signed-off-by: Radim Krčmář <[email protected]>
Other cur_ helpers use small case; make architecture follow the convention. Signed-off-by: Radim Krčmář <[email protected]>
Sail code can use architecture call incorrectly, which currently results in a mapping error in architecture(). There is only one possible error value, but the error is more obvious if we state it explicitly. Internal error will hopefully also dump the call stack, which the mapping error might not do. Signed-off-by: Radim Krčmář <[email protected]>
Current architecture never changed the behavior, so there is no reason to complicate the code with it. We duplicate code, so this should be rewritten when/if Sail supports multiple matches like: User | Supervisor if mstatus[TVM] == 0b1 => ... Machine | Supervisor if mstatus[TVM] == 0b0 => ... where `if` has higher priority than `|`, so we could also write (foo if a | bar if b) if c => Signed-off-by: Radim Krčmář <[email protected]>
No functional change, initialize with zeros() for increased sanity. Signed-off-by: Radim Krčmář <[email protected]>
SXL and UXL fields are WPRI on RV32, so RV32 doesn't need to look at them. We return correct [SU]XLEN on RV32 witout depending on SXL/UXL and having zeros in mstatus register will allow its simplification. Signed-off-by: Radim Krčmář <[email protected]>
Like the TODO comment wanted. Signed-off-by: Radim Krčmář <[email protected]>
The register can have any representation in the implementation as long as the CSR interface is correct. Use 64 bits for internal implementation of mstatus instead of xlen. Make sstatus the same size to reduce code friction. Remove mstatush and represent it as a view into higher bits of the mstatus register. Signed-off-by: Radim Krčmář <[email protected]>
The writes currently can't change anything, but make the code ready for future extensions. Signed-off-by: Radim Krčmář <[email protected]>
SD bit is read-only and we don't have to store it anywhere. Make SD dynamic to provide more flexibility when implementing RV128 and XLEN != MXLEN, because sstatus has SD position decided by SXL. Signed-off-by: Radim Krčmář <[email protected]>
Add new fields to the structure and make them constant zero on RV32 and misa[MXL] on RV64. Remove [SU]XL accessors to make the code cleaner. Signed-off-by: Radim Krčmář <[email protected]>
Make the code nicer, even if they are always zero. Signed-off-by: Radim Krčmář <[email protected]>
UBE felt left out because MBE and SBE are already there. Add useless UBE field. Signed-off-by: Radim Krčmář <[email protected]>
Thanks for this change, I haven't had a detailed look at it yet but it seems some of the changes conflict with https://github.com/riscv/sail-riscv/pull/652/files which will most likely be merged soon. @Timmmm could you take a look and see which one is better or if we want both changes? |
The pull request also expands the status to bits(64) and explicitly copies the fields, so I can drop 4 patches. I will rebase when it lands and add 2 patches to clean up its handling of SXL/UXL and SD. |
This series started by noticing that we use SXL in RV32 mode, which results in very ugly accessors for mstatus. The code around mstatus can be improved by changing the architecture (XLEN) detection.
There is (should be) no functional change.