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
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.
The text was updated successfully, but these errors were encountered:
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
csrs
andcsrc
. 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.The text was updated successfully, but these errors were encountered: