Re: Fast-track extension proposal for "Hardware Performance Monitor count overflow and mode-based event filtering"
On Mon, Feb 1, 2021 at 10:00 AM Brian Grayson <brian.grayson@...> wrote:
Using 'hpm' probably would be a bit confusing. But I'll look into alternatives. Btw, since a new extension naming standard is being developed, ultimately this (and all other extensions) will need to conform to the new scheme (although the 'Ss' part of this name is expected to be consistent with that new scheme). Also note that CMO group extensions will have "Zi*" names and the concern over use of "co" or "cop" as a root name was particularly in that context (i.e. wrt other Unpriv spec extensions; while this extension in the "S" name space for Priv extensions). But in any case I'll explore alternatives that may be acceptable.
This has been discussed (with the lead architects; I'll stop repeatedly mentioning this). And in standard RISC philosophy form, it was considered to have insufficient justification. For a core with S-mode and if M-mode wants to examine the bits for counters that have not been "delegated" down to S-mode via mcounteren, then M-mode can either use a three-instruction sequence to read a version of scountovf unaffected by mcounteren, or it can directly check the individual mhpmevent.OF bits that it cares about. The latter also applies for a core without S-mode that implements this extension. (Further, I imagine a "no S-mode" CPU probably only implements a small number of counters.)
The Priv spec says "The mhpmcounters are WARL registers that support up to 64 bits of precision". This allows complete flexibility for how many implemented bits there are.
Since count values are defined as unsigned, there is always an equivalent unsigned 64-bit current count value irrespective of the implemented size. So overflow is well-defined (modulo the issue down below).
This would be an issue to raise with the existing Priv spec, not with this extension. But as noted above, this isn't really an issue since it is already comprehended by the Priv spec.
Good point. The current proposed definition doesn't properly comprehend the WARL nature of the hpmcounter registers. I'll switch to a definition along the lines of what you describe (I agree that that is what is needed). Count values remain as unsigned values and overflow is unsigned overflow of the implemented bits.