Clarify: non-existent CSR access raises an exception.#791
Conversation
|
This may seem strange, but it's not clear to me what a "CSR" is in this context. Say that we have a single trigger that is hardwired with type=tmexttrigger. Then tdata3 doesn't exist. So presumably accessing tdata3 will trap. That's fine. Say that we have two triggers where the first is as above and the second has type=mcontrol6. If tselect points to the second trigger then accessing tdata3 (textra) doesn't trap. But is it supposed to trap if tselect points to the first trigger? Even worse, say that one of the supported triggers allows type to be either tmexttrigger or mcontrol6. Are accesses to tdata3 supposed to trap based on the type field of tdata1 when tselect points to this trigger? I'm hoping that "CSR" for purposes of this issue means scontext, hcontext, tselect, tdata1, tdata2, tdata3, tinfo, tcontrol, mcontext, mscontext and that it does not mean the underlying state that is indirectly referenced via tselect. |
|
What makes sense to me is that tdataN are implemented if any of the triggers that are implemented require it. So if any of the triggers support type 6, then tdata2 must not trap when accessed, even if the currently selected trigger only supports tmexttrigger. I think only tdata2 is affected by this. tdata1 is required for any triggers at all, and tdata3 is orthogonal to trigger type. I think I just wrote that I agree with you. Is that right? |
|
I believe that we agree. Basically, the trap happens solely based on the instruction encoding (specifically the top 12 bits that encode the CSR number) regardless of the values in any other CSRs (such as tselect). That should be clearer in the PR. |
ee529e0 to
0a895b9
Compare
|
I think I've clarified this. |
0a895b9 to
5a487e9
Compare
Paul Donahue (pdonahue-ventana)
left a comment
There was a problem hiding this comment.
I made a comment but it was sitting in a pending review. I visited this page a few times (where the comment was visible to me) to see if you replied. Now I understand why you didn't.
The privileged spec already requires this. This addresses a mailing list discussion subject:"Clarification of enumeration procedure in Sdtrig ISA extension"
5a487e9 to
efb16bc
Compare
Paul Donahue (pdonahue-ventana)
left a comment
There was a problem hiding this comment.
👍
The privileged spec already requires this.
This addresses a mailing list discussion subject:Clarification of enumeration procedure in Sdtrig ISA extension