I think the specification for xscratchcsw[l] could be significantly simplified and tightened up to avoid implementation defined behaviour by changing it to be something like this:
xscratchcsw and xscratchcswl have behaviour that depends on a condition, respectively:
the current privilege is not equal to the previous privilege
the current interrupt level ....
If the condition is true, then csr* rd, xscratchcsw[l], rs1/imm behaves the same as csr* rd, xscratch, rs1/imm. Otherwise it behaves the same as mv rd, rs1/imm.
This is way simpler to understand, and avoids all of the ambiguity around csrs and csrc. It's the most obvious thing to do, and it is also what we have implemented in the Sail model (not upstreamed yet) and in our designs.
Potentially something similar could be done for xnxti but I haven't fully understood that bit of the spec yet.
I think the specification for
xscratchcsw[l]could be significantly simplified and tightened up to avoid implementation defined behaviour by changing it to be something like this:This is way simpler to understand, and avoids all of the ambiguity around
csrsandcsrc. It's the most obvious thing to do, and it is also what we have implemented in the Sail model (not upstreamed yet) and in our designs.Potentially something similar could be done for
xnxtibut I haven't fully understood that bit of the spec yet.