How to trace cm.popret when interrupted after final load/store

[j0106223]

When data trace is implemented, instructions that perform multiple memory accesses must be reported multiple times on the instruction trace infterface.

If an interrupt occurs after the final load operation of a cm.popret instruction completes but before the remaining atomic operations (e.g., stack pointer update and return) are executed, how should this be reported in the instruction trace?

Example:

For a cm.popret instruction, if the final load completes and is reported with itype = 13 (indicating a return), this could cause confusion, as the actual "return" operation has not occurred due to the interrupt.

This issue also applies to cm.pop and cm.push instructions:

The final load or store may be reported as if the entire instruction has retired, even though the remaining atomic operations were not completed due to the interrupt.

Question Summary:

• Should the final load/store be reported on the instruction trace interface if an interrupt occurs before the instruction fully completes?
• If it must be reported, what itype value should be used to avoid falsely indicating that the instruction has fully retired?

[IainCRobertson]

Jack, The normal rules about instruction trace apply. If there was no data trace, then the cm.popret would be reported as retired with itype=13 on the trace interface when all actions initiated by the instruction had completed (i.e. when the return completed). With data trace, it's necessary to report a retired instruction along with each load/store so that the encoder knows which instruction address the load/store is associated with. So if the hart reports the final load to the encoder before it would otherwise have reported the instruction as retired then it needs to use itype = 0 for that, and then follow with itype = 13 when the instruction actually retires. Iain From: JACK-YEH ***@***.***> Sent: 05 June 2025 08:37 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] How to trace cm.popret when interrupted after final load/store (Issue #235) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 created an issue (riscv-non-isa/riscv-trace-spec#235)<#235> When data trace is implemented, instructions that perform multiple memory accesses must be reported multiple times on the instruction trace infterface. If an interrupt occurs after the final load operation of a cm.popret instruction completes but before the remaining atomic operations (e.g., stack pointer update and return) are executed, how should this be reported in the instruction trace? Example: For a cm.popret instruction, if the final load completes and is reported with itype = 13 (indicating a return), this could cause confusion, as the actual "return" operation has not occurred due to the interrupt. This issue also applies to cm.pop and cm.push instructions: The final load or store may be reported as if the entire instruction has retired, even though the remaining atomic operations were not completed due to the interrupt. Question Summary: * Should the final load/store be reported on the instruction trace interface if an interrupt occurs before the instruction fully completes? * If it must be reported, what itype value should be used to avoid falsely indicating that the instruction has fully retired? - Reply to this email directly, view it on GitHub<#235>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSUWUD3YNEROWETOHCD3B7XRDAVCNFSM6AAAAAB6UUCDBGVHI2DSMVQWIX3LMV43ASLTON2WKOZTGEZDAMJWG42DOMI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[j0106223]

Hi Iain,

In the 4-load cm.popret example given in Section 4.3, is it assumed that the final load and the return operation are performed atomically or as a single step?

If, in an implementation, the final load is not performed atomically with the subsequent micro-operations, would the retire sequence look something like the following?

1. iretire != 0 and itype = 0, iaddr = pc (1st instruction retired in this block);

2. iretire = 1 and itype = 0, iaddr = pc(cm.popret);

3. iretire = 1 and itype = 0, iaddr = pc(cm.popret);

4. iretire = 1 and itype = 0, iaddr = pc(cm.popret);

5. iretire = 0 and itype = 2, iaddr = pc(cm.popret);

6. interrupt taken

7. trap to interrupt handler
   ...
   ...
   ...

8. return from interrupt handler

(According to the specification: If an exception occurs partway through the sequence of loads or stores initiated by such an instruction, and the instruction is re-executed after the exception handler has been serviced, the load or store sequence must recommence from the beginning.)

Re-execute cm.popret:

9. iretire != 0 and itype = 0, iaddr = pc (1st instruction retired in this block);
10. iretire = 1 and itype = 0, iaddr = pc(cm.popret);
11. iretire = 1 and itype = 0, iaddr = pc(cm.popret);
12. iretire = 1 and itype = 0, iaddr = pc(cm.popret);
13. iretire = 1 and itype = 13, iaddr = pc(cm.popret);

[IainCRobertson]

Jack, Yes, that's correct. Iain From: JACK-YEH ***@***.***> Sent: 05 June 2025 10:00 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] How to trace cm.popret when interrupted after final load/store (Issue #235) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 left a comment (riscv-non-isa/riscv-trace-spec#235)<#235 (comment)> Hi Iain, In the example given in section 4.3, is it assumed that the final load and the return operation in cm.popret are performed atomically or as a single step? If, in an implementation, the final load is not performed atomically with the subsequent micro-operations, would the retire sequence look something like the following? 1. iretire != 0 and itype = 0, iaddr = pc (1st instruction retired in this block); 2. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 3. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 4. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 5. interrupt taken 6. trap to interrupt handler ... ... ... 7. return from interrupt handler (According to the specification: If an exception occurs partway through the sequence of loads or stores initiated by such an instruction, and the instruction is re-executed after the exception handler has been serviced, the load or store sequence must recommence from the beginning.) Re-executed cm.popret: 1. iretire != 0 and itype = 0, iaddr = pc (1st instruction retired in this block); 2. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 3. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 4. iretire = 1 and itype = 0, iaddr = pc(cm.popret); 5. iretire = 1 and itype = 13, iaddr = pc(cm.popret); - Reply to this email directly, view it on GitHub<#235 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSQG34PM7WTA33RKRJD3CABH5AVCNFSM6AAAAAB6UUCDBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNBTGMZTMMJTHA>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[j0106223]

Hi Iain,

Therefore, the following statement in section 4.3 Data Trace Interface requirements should be revised or clarified in the specification.

for the final load or store, which must retire using the natural itype for the instruction
(for example, a cm.popret instruction must use itype 13 for the final load to signal the return).

The reason is that there is no guarantee the final load can complete atomically together with subsequent operations. As specified in The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture, Version 20250508, section 28.13.3 PUSH/POP Fault handling,

It is implementation defined whether interrupts can also be taken during the sequence execution.

Furthermore, the specification only states that the micro-operations after all loads/stores are considered atomic — this atomicity does not include the final load itself.

Best regards,
Jack

[j0106223]

Hi Iain,

Are there any updates on this issue?

Best regards,
Jack

[IainCRobertson]

Jack, The ticket is open, and I'll look to update the wording in the next update to the E-Trace spec. Unfortunately this one came in too late to make the last version, which was only recently published. Because this is a ratified standard, there is fairly lengthy process (including 2 week public review) for any changes so I can't do this too often. Iain From: JACK-YEH ***@***.***> Sent: 01 July 2025 10:19 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] How to trace cm.popret when interrupted after final load/store (Issue #235) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 left a comment (riscv-non-isa/riscv-trace-spec#235)<#235 (comment)> Hi Iain, Is there any updates on this issue? Best regards, Jack - Reply to this email directly, view it on GitHub<#235 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXUI5VW3MLOYYQCGIT3GJHBLAVCNFSM6AAAAAB6UUCDBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMRSHEYDMMZXGQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[j0106223]

Hi Iain,

Thanks a lot.

Best regards,
Jack