PUSH/POP Fault handling

[j0106223]

Hi Iain,

In the Hart to Trace Interface Specification, section 2.4.1 Multi-memory-access Instructions states:

The final load/store initiated by the instruction must be reported at the same time as the instruction retires (i.e., dretire and iretire active simultaneously).

However, after the loads or stores have completed, the remaining micro-operations, such as stack pointer updates, may still be interrupted, preventing the push/pop instruction from retiring. In this scenario, how should the final load/store be reported? It has indeed completed the final load/store, but there is no corresponding iretire for it.

Best regards,
Jack

[IainCRobertson]

Interesting question. I think the requirement can be relaxed from "must" to "may".

[IainCRobertson]

How about this: #79

[j0106223]

I still think we should use "must". The point of "must be reported at the same time as the instruction retires" is to associate with the retiring instruction. If the instruction never retires, there is no association possible and we do not care.

It seems no changes to the spec are necessary.

Thanks.

[IainCRobertson]

I don't follow your reasoning here. The loads/stores will be set aside in the "stack-like structure" in the decoder until the instruction retires. The encoder will generate the same packets for the loads/stores regardless of whether the final one is reported on the interface at the same time as the instruction or not, and decoding for push/pop does not rely on timestamps on the trace packets.

The disadvantage of having to delay reporting the final load/store until the instruction retires if interrupts are supported is that the hart will need to hold this information in a temp register somewhere until after the interrupt handler completes. And if the interrupt itself includes a push/pop, the same thing could happen again, which would require multiple temp registers or something to prevent nested interrupts during the push/pop. That all gets pretty messy! Allowing the hart to report the final load/store when it happens avoids all that. For harts that don't allow interrupting push/pop, reporting the final load/store at the same time as the instruction retirement may be simpler.

[j0106223]

Hi Iain,

In issue #54 , you gave the reason why the final dretire should align with iretire, as follows:

Yes, the final dretire should align with iretire. The issue with allowing dretire to occur at other times (provided the instruction info is valid) is that it may lead to misleading timestamp information. For example, if a load or store instruction is reported in the instruction trace stream (via a sync packet, or because of a watchpoint notification or because it's the target of an uninferable jump) as well as the data trace stream, it's desirable that the two packets have the same timestamp. This can't be guaranteed if dretire and iretire don't occur on the same cycle.

It seems this view may differ from your current opinion.

Best regards,
Jack

[IainCRobertson]

Jack, I did say that, didn't I! And that is certainly true for "normal" loads and stores. Thinking about it some more I don't think it's important for MMA load/stores though. All the te_data packets for the earlier loads/stores in the sequence will have earlier timestamps than the instruction retirement, and I don't think it makes any material difference whether the last one has an aligned timestamp or not. The situation where the timestamp is important is for recovery from data trace lost. Once data trace restarts, the 1st instruction retirement where data trace is no longer blocked will produce a sync packet. The 1st data trace packet will also have a timestamp, and the decoder can associate this with the 1st load/store instruction that has the same or later timestamp as the te_inst sync packet. Data trace loss could occur part way through an MMA sequence (i.e. some MMAs are traced and on the decoder's stack). Similarly, the recovery could start part way through an MMA sequence (only the last MMAs in that sequence get traced). To avoid issues resyncing, any MMAs on the decoder's stack must be discarded when loss occurs. On recovery, for the 1st retired MMA instruction, somewhere between all and none of the MMA loads/stores will be on the stack. The decoder can pop what's there and report it to the user (knowing it may be an incomplete list). If the final load/store is retired at the same time as the instruction vs earlier, it means that if this is the 1st instruction after recovery, you might get one MMA load/store on the stack rather than none. I don't think that really matters. Iain From: JACK-YEH ***@***.***> Sent: 07 January 2026 05:50 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] PUSH/POP Fault handling (Issue #73) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 left a comment (riscv-non-isa/hart-trace-interface#73)<#73 (comment)> Hi Iain, In issue #54<#54> , you gave the reason why the final dretire should align with iretire, as follows: Yes, the final dretire should align with iretire. The issue with allowing dretire to occur at other times (provided the instruction info is valid) is that it may lead to misleading timestamp information. For example, if a load or store instruction is reported in the instruction trace stream (via a sync packet, or because of a watchpoint notification or because it's the target of an uninferable jump) as well as the data trace stream, it's desirable that the two packets have the same timestamp. This can't be guaranteed if dretire and iretire don't occur on the same cycle. It seems this view may differ from your current opinion. Best regards, Jack - Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSSDPMKXKCRDY3IMEM34FSNALAVCNFSM6AAAAACPBM3XKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJXGQYTMNBQHE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[j0106223]

Hi Iain,

Given this, would it make sense to update the spec wording to explicitly allow the final load/store of an MMA instruction to be reported before the instruction retires?

Best regards,
Jack

[IainCRobertson]

Jack, That's what "may" means (as opposed to must). May is optional, which by definition means the final load or store could be earlier. So I don't think it needs changing. Iain From: JACK-YEH ***@***.***> Sent: 07 January 2026 11:45 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] PUSH/POP Fault handling (Issue #73) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 left a comment (riscv-non-isa/hart-trace-interface#73)<#73 (comment)> Hi Iain, Given this, would it make sense to update the spec wording to explicitly allow the final load/store of an MMA instruction to be reported before the instruction retires? Best regards, Jack - Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSVU2OCLU33HZVQMIUL4FTWVRAVCNFSM6AAAAACPBM3XKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJYGUYDAMRWHE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[j0106223]

Using “may” here is ambiguous and could be read as allowing the final load/store to be reported after iretire.

[IainCRobertson]

Jack, Okay, that's fair - I will amend to make it clear that it may be before but cannot be after. I'll roll this in with any public review comments. Iain From: JACK-YEH ***@***.***> Sent: 07 January 2026 14:18 To: riscv-non-isa/hart-trace-interface ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/hart-trace-interface] PUSH/POP Fault handling (Issue #73) [https://avatars.githubusercontent.com/u/48269434?s=20&v=4]j0106223 left a comment (riscv-non-isa/hart-trace-interface#73)<#73 (comment)> Using "may" here is ambiguous and could be read as allowing the final load/store to be reported after iretire. - Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSTEW6VJ3C24MX3EPOD4FUIQ3AVCNFSM6AAAAACPBM3XKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJZGA4TGNRYGE>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[j0106223]

Thank you.