riscv-isa-manual
riscv-isa-manual copied to clipboard
riscv
Write to MCAUSE / ExceptionCode
Asking for clarification on the following. In the Privileged spec it says for Writes to the MCAUSE[Exception Code]
The Exception Code is a WLRL field, so is only guaranteed to hold supported exception codes.
So if I have a device which does not support supervisor, and I attempt to write the value 0x80000001 (Supervisor Software Interrupt) Does this mean the MCAUSE should remain unchanged ? And secondly, no Reserved values can be written ?
The additional wording 'guaranteed' makes it appear possible that the unsupported exception codes are optional, so I want to be clear that what this actually means is the following
The Exception Code is a WLRL field, so must only hold supported exception codes.
(sorry to be pedantic, but it does actually matter)
Thx Lee
The answer follows from the definition of WLRL: https://github.com/riscv/riscv-isa-manual/blob/16f50025273b68de34a4b7c7a397538bd9d508ed/src/priv-csrs.tex#L445
To add more detail: WLRL is a lot like WARL, except illegal values are not required to be transformed into legal values; So legal values map to legal values; illegal values can map to anything (as long as it is deterministically dependent on the current state of the field and the value being written) and/or cause an illegal exception (which is one of the few data-dependent traps that exist, I think).
There is a slight difference between that deterministic wording compared to WARL, which states it is deterministically dependent on the current state of the hart and the value being written; WARL was changed because it became clear that what was illegal for some fields can be determined by other state.
There are only 3 WLRL fields (unused MISA fields, the exception code in xCAUSE (I'm counting it only once), and VGEIN field in HSTATUS
On Fri, Oct 9, 2020 at 12:30 PM Andrew Waterman [email protected] wrote:
The answer follows from the definition of WLRL: https://github.com/riscv/riscv-isa-manual/blob/16f50025273b68de34a4b7c7a397538bd9d508ed/src/priv-csrs.tex#L445
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/597#issuecomment-706364592, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWDNW6RZLC4KKFZMSTSJ5QEVANCNFSM4SKDJIWQ .
@allenjbaum
illegal values can map to anything
This does not make sense, if the field is WLRL, your statement implies that illegal can map to illegal (ie anything)
Or did you mean illegal can map to any LEGAL value ?
** Update ** Re-reading your post, I think you are saying that it can in fact hold illegal values, thanks - now I understand, going back and RTFM I think does describe this for WLRL.
No, I meant exactly what I said: it can map to anything - at least, that is my interpretation of what the definition of WLRL says: "Implementations can return arbitrary bit patterns on the read of a WLRL field when the last write was of an illegal value" If you write an illegal value, all bets are off. It can replace it with a legal value, or any other illegal value or trap or both. If it hurts when you do that, then don't do that. WARL has to map to a legal value - WLRL does not. I believe the intent is that if legal values can fit into a smaller number of bits than the field can represent, then an attempt to write some larger number of (non-zero) bits can simply truncate the value to fit just the number of bits that a legal value uses. In that case, what is written is neither the original illegal value being written, the current value of the field, or some legal value. The spec definition is much looser than that truncation, however.
On Sun, Oct 11, 2020 at 11:35 PM eroom [email protected] wrote:
@allenjbaum https://github.com/allenjbaum
illegal values can map to anything
This does not make sense, if the field is WLRL, your statement implies that illegal can map to illegal (ie anything)
Or did you mean illegal can map to any LEGAL value ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/597#issuecomment-706902145, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJXZ5GHC2QYFOUVWMZLSKKPSZANCNFSM4SKDJIWQ .
The spec definition is much looser
Yes, the intent was also to permit compression of a sparse set of legal values. If the set of legal values is 0, 7, and 11, we'd like to encode those in 2 bits rather than 4.