Open dansmathers opened 1 year ago
If certain CSR instruction encodings are "reserved" then that falls into "the behavior upon decoding a reserved instruction is UNSPECIFIED" which is intentionally unconstrained per unpriv spec section 1.7.
maybe use different words for things that are undefined vs constrained defined (e.g. the implemented behavior must be one of an explicitly-defined set).
Do you have any examples of things that are constrained defined in RISC-V (not ARM)? There are a few "it is UNSPECIFIED whether A or B happens" in the debug spec but I don't think that there's anything like that in the priv or unpriv specs.
There are several places where constrained behavior happens that I can think of (e.g. the poster child: misaligned access: does it trap or not, and does it even deterministically trap) Beyond that, even, a misaligned access to an address that it doesn't have permissions to access could signal either misaligned or access violation. Beyond that, even, a misaligned access to an address that it doesn't have permissions to access could store the half that it does have access to - or not. And not necessarily deterministically. That might not be what you mean by constrained behavior Vector has constrained behavior around tail and mask agnostic - that might be a better example I thought there were (other) cases where CSRRW and CSRRS had different behaviors than CSRRW, though I can't come up with the case I'm thinking of. (or maybe this is the case I'm thinking of.. but check AIA to see if it does something like that)
Constrained behavior - from an ACT point of view, is more problematic than reserved behavior, ironically. If it is reserved, ACTs will never try to test its behavior. But if it constrained, it must test to see that it meets the constraint - and if it is non-deterministically constrained, we can't use the Sail or Spike vs DUT testing model, we have to use completely different kinds of tests. And the looser the constraints (that is if there are more than 2 legal outcomes) , the more difficult it is to test.
So: just make CSRRW[I], CSRR[S,C} reserved for that CSR. Or define them so they do what you would expect, even if it isn't useful,
On Mon, Dec 5, 2022 at 3:17 PM Paul Donahue @.***> wrote:
If certain CSR instruction encodings are "reserved" then that falls into "the behavior upon decoding a reserved instruction is UNSPECIFIED" which is intentionally unconstrained per unpriv spec section 1.7.
maybe use different words for things that are undefined vs constrained defined (e.g. the implemented behavior must be one of an explicitly-defined set).
Do you have any examples of things that are constrained defined in RISC-V (not ARM)? There are a few "it is UNSPECIFIED whether A or B happens" in the debug spec but I don't think that there's anything like that in the priv or unpriv specs.
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/924#issuecomment-1338328484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJX6I6HZR2M4ULMZTD3WLZZZDANCNFSM6AAAAAASUZD5L4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
the RISC-V unprivileged and privileged specs use the term reserved in a couple ways. e.g. Reserved encodings are currently not defined but are saved for future standard extensions. The behavior upon decoding a reserved instruction is unspecified.
The other bits in mstatus are reserved; software should write zeros and hardware implementations should return zeros.
The CLIC specification was trying to reserve CSR instruction behavior, e.g. only define xnxti using CSRRSI/CSRRCI. Accessing the xnxti CSR using any other CSR instruction form (CSRRW/CSRRS,rs1!=x0/CSRRC/CSRRWI) is reserved. Note: Use of xnxti with CSRRSI with non-zero uimm values for bits 0, 2, and 4 are reserved for future use.
Should the definition of reserved in the unprivileged and privileged manuals be revisited? maybe use different words for things that are undefined vs constrained defined (e.g. the implemented behavior must be one of an explicitly-defined set).
See issue https://github.com/riscv/riscv-fast-interrupt/issues/289 for more background.