-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use resumereq instead of DRET #132
base: main
Are you sure you want to change the base?
Conversation
Agreed that dret is not a "real" instruction, hence why we included this note:
DRET is a common way of implementing return from DRET, so I personally think its clearer to have a dedicated note for this as it helps designers implementing CHERI processors. |
I think we are losing the fact that PCC is restored by unsealing DPCC on exit from debug mode. I'm happy to remove the dret definition and add a note that DRET is a common implementation choice instead. We just need to mention that PCC also needs to be restored when this architectural state transition happens. Maybe the easiest solution is to add a DPCC subsection after the current DDDC one? |
I find this language confusing. Pseudoinstructions in RISC-V are assembly mnemonics that correspond to an instruction but are not that instruction's canonical mnemonic, or that expand to more than one instruction. DRET isn't a pseudoinstruction, if it exists at all it's a real instruction. The language about "does not execute from the program buffer" appears to be the result of a misparse of the debug specification: dret executes normally, but only when injected by the debug module, it is not meaningful to attempt to use it in the program buffer.
If you try to implement an "A.2. Execution Based" debug mechanism, you'll fail immediately because all three CHERI extensions initialize D mode in Capability mode and we haven't defined anything to allow x0 to be used as a base register in D/Capability mode... I haven't figured out yet what I want to do here.
I'll update this later and also align better with debug spec terminology. |
DRET is not a standard instruction. Its only mention in the debug spec is in a non-normative section describing a single possible implementation, in a clause describing how the debug module might internally implement the dmstatus.resumereq field. While DRET has a reserved opcode for implementations which use it or something like it, it is itself a custom extension whenever it appears. Describe CHERI functions in terms of the architectural dmstatus.resumereq instead of the non-architectural DRET. Signed-off-by: Stefan O'Rear <[email protected]>
This mirrors Appendix A in the debug specification to describe how the illustrative implementations have to be adapted for Zcheri_purecap and Zcheri_legacy. Signed-off-by: Stefan O'Rear <[email protected]>
This already exists in <>. I added a brief section adapting Appendix A of the debug spec to CHERI to describe dret operation when it exists. |
DRET is not a standard instruction. Its only mention in the debug spec is in a non-normative section describing a single possible implementation, in a clause describing how the debug module might internally implement the dmstatus.resumereq field. While DRET has a reserved opcode for implementations which use it or something like it, it is itself a custom extension whenever it appears.
Describe CHERI functions in terms of the architectural dmstatus.resumereq instead of the non-architectural DRET.