Date
1 - 2 of 2
unsupported counters
|
Beeman Strong
Hi there, For an implementation that does not support all 29 programmable HPM counters, what is the expected behavior of bits in mcountinhibit and xcounteren associated with the unsupported counters? If hpmevent31 and hpmcounter31 are read-only 0, should mcountinhibit[31] and xcounteren[31] also be read-only 0? thanks, beeman |
|
|
|
Andrew Waterman
The implementation has some latitude here, but implementations I’m aware of do hardwire all these bits to zero in that case. If the corresponding xcounteren bits are read-only zero, then unprivileged accesses to the counter will trap. If that’s acceptable, then go for it. If you want unprivileged software to be able to access the counter (which admittedly isn’t terribly useful if it’s hardwired to zero), then don’t hardwire the xcounteren bit to zero. I would recommend making the mcountinhibit but read-only, since making it writable serves no purpose if the counter is read-only zero. But this also isn’t a strict requirement. On Fri, Jan 13, 2023 at 11:35 AM Beeman Strong <beeman@...> wrote:
|
|
|