Fair enough.  But it would be nice to have the full definition of instret in one place.  To discern that instructions that cause exceptions don't increment the counter requires reading the ECALL/EBREAK description.  Perhaps the following change would be reasonable:

M-mode includes a basic hardware performance-monitoring facility. The mcycle CSR counts the
number of clock cycles executed by the processor core on which the hart is running. The minstret
CSR counts the number of instructions the hart has retired. The mcycle and minstret registers
have 64-bit precision on all RV32 and RV64 systems.

========== NEW non-normative text ==========

Instructions that cause synchronous exceptions, including ECALL and EBREAK, are not considered to retire and hence do not increment the minstret CSR.  

On Fri, Oct 29, 2021 at 9:57 AM Greg Favor <gfavor@...> wrote:

On Fri, Oct 29, 2021 at 9:15 AM Beeman Strong <beeman@...> wrote:

Thanks guys.  It would be good to clarify this in the spec, so there is no confusion.  x86's INST_RETIRED.ALL, for instance, does increment for interrupts and exceptions.

I don't argue against a non-normative clarification, but a direct literal reading of the RV text (i.e. only completed/retired instructions are counted) leaves no ambiguity.  Taking an interrupt or an exception does not correspond to execution of any instruction in the program.  It's an interesting event, but it's not the execution and retirement of an instruction.  (Similarly, executing an instruction, causing cache/TLB misses, and causing other lasting uarch effects, but ultimately not retiring the instruction, must not be counted even though real effects with performance implications have been caused.) 

As far as adding clarification because another architecture has a different definition of something (in this case a specific perf event), this starts down a long slippery slope - across the RV arch specs - of countering people's presumptions based on x86 or ARM or MIPS or ....  Currently the RV arch specs expect people to fully read the spec and to not presume meanings or behaviors that may happen to be true in other architectures.  Other architectures take the same tack.  Conversely, in practice, there will be people that only do a quick or loose read of some arch text, don't read other related sections of the arch specs, and bring in their own interpretative presumptions.  Trying to defend against all that would ultimately result in lots and lots of clarifications. (And discussions over where to draw the line.)

Greg