EPC behavior

[pdonahue-ventana]

I don't understand this sentence in the trace spec:

(The reason for not reporting the EPC for all exceptions when thaddr is 0 is that it may be at either the address of the next instruction or current instruction depending on the exception cause, which can be inferred by the decoder without adding complexity to the encoder.)

mepc is defined as:

mepc is written with the virtual address of the instruction that was interrupted or that encountered the exception.

Thanks to the fact that ebreak and ecall are defined to never retire, EPC always points to the first instruction that did not retire. For instance, it points to the load that got a page fault (and trapped instead of retiring), the ecall/ebreak (that trapped instead of retiring), or the first unretired instruction on an interrupt. Other architectures may do EPC=PC+4 on an ecall and some other cases where the handler is expected not to re-execute the instruction but RISC-V puts the burden of incrementing EPC on the handler.

Am I misunderstanding the purpose of this sentence or does this sentence assume some variability of EPC behavior on RISC-V that doesn't exist?

[IainCRobertson]

Paul, I don't think this sentence is correct either, given the current defined behaviour of mepc. I think there is history here. When I originally wrote this I was under the impression that ecall and ebreak retired. As you have previously stated, this was clarified in the priv spec back in 2019, but I wasn't aware of that clarification until much later. So certainly I think we should remove or amend this paragraph. If this wasn't a ratified spec, I'd suggest removing the paragraph completely and updating the definition of thaddr in table 17 to say that if thaddr = 0, the address field always reports the EPC. However, I'm wary about doing that as it could be viewed as a normative change. The only justification here would be that actually the "undefined" value being produced by any current HW will almost certainly actually be the value from the iaddress input when itype was 1, because it would cost extra gates to do otherwise so why would anyone do that? But if we want to avoid the risk of a potentially normative change then the final part of the paragraph, which states that the EPC can be deduced by the decoder is still true however. So my suggestion would be to reword as follows: (The reason for not reporting the EPC for all exceptions when thaddr is 0 is that it can be inferred by the decoder.) Thoughts? Iain From: Paul Donahue ***@***.***> Sent: 04 March 2025 23:43 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] EPC behavior (Issue #210) I don't understand this sentence<https://github.com/riscv-non-isa/riscv-trace-spec/blob/main/payload.adoc?plain=1#L204> in the trace spec: (The reason for not reporting the EPC for all exceptions when thaddr is 0 is that it may be at either the address of the next instruction or current instruction depending on the exception cause, which can be inferred by the decoder without adding complexity to the encoder.) mepc is defined as<https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L1698>: mepc is written with the virtual address of the instruction that was interrupted or that encountered the exception. Thanks to the fact that ebreak and ecall are defined to never retire, EPC always points to the first instruction that did not retire. For instance, it points to the load that got a page fault (and trapped instead of retiring), the ecall/ebreak (that trapped instead of retiring), or the first unretired instruction on an interrupt. Other architectures may do EPC=PC+4 on an ecall and some other cases where the handler is expected not to re-execute the instruction but RISC-V puts the burden of incrementing EPC on the handler. Am I misunderstanding the purpose of this sentence or does this sentence assume some variability of EPC behavior on RISC-V that doesn't exist? - Reply to this email directly, view it on GitHub<#210>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSSHB7IBFL3QZUM3ECL2SY3ARAVCNFSM6AAAAABYKXNPJGVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA4TKNZRGU3TSMI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>> [pdonahue-ventana]pdonahue-ventana created an issue (riscv-non-isa/riscv-trace-spec#210)<#210> I don't understand this sentence<https://github.com/riscv-non-isa/riscv-trace-spec/blob/main/payload.adoc?plain=1#L204> in the trace spec: (The reason for not reporting the EPC for all exceptions when thaddr is 0 is that it may be at either the address of the next instruction or current instruction depending on the exception cause, which can be inferred by the decoder without adding complexity to the encoder.) mepc is defined as<https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L1698>: mepc is written with the virtual address of the instruction that was interrupted or that encountered the exception. Thanks to the fact that ebreak and ecall are defined to never retire, EPC always points to the first instruction that did not retire. For instance, it points to the load that got a page fault (and trapped instead of retiring), the ecall/ebreak (that trapped instead of retiring), or the first unretired instruction on an interrupt. Other architectures may do EPC=PC+4 on an ecall and some other cases where the handler is expected not to re-execute the instruction but RISC-V puts the burden of incrementing EPC on the handler. Am I misunderstanding the purpose of this sentence or does this sentence assume some variability of EPC behavior on RISC-V that doesn't exist? - Reply to this email directly, view it on GitHub<#210>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSSHB7IBFL3QZUM3ECL2SY3ARAVCNFSM6AAAAABYKXNPJGVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA4TKNZRGU3TSMI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[pdonahue-ventana]

(The reason for not reporting the EPC for all exceptions when thaddr is 0 is that it can be inferred by the decoder.)

I understand your confusion 5-6 years ago about ecall/ebreak because I was also confused at that time. Your new proposed text removes the confusion and maintains backward compatibility both with existing encoders and decoders. That seems like the ideal solution at this point.

For extra credit, this could probably be written as a non-normative [NOTE] instead of in parentheses.

[IainCRobertson]

@pdonahue-ventana see #212.

[pdonahue-ventana]

Looks good.