Re: Non-idempotent PMA and table walk accesses

Greg Favor

For reference here is ARMv8's definition of idempotency (which includes side-effects):

The Normal memory attribute is appropriate for locations of memory that are idempotent, meaning that they exhibit all of the following properties:
— Read accesses can be repeated with no side-effects.
— Repeated read accesses return the last value written to the resource being read.
— Read accesses can fetch additional memory locations with no side-effects.
— Write accesses can be repeated with no side-effects if the contents of the location accessed are unchanged between the repeated writes or as the result of an exception, as described in this section.
— Unaligned accesses can be supported.
— Accesses can be merged before accessing the target memory system.

Put very concisely (and stripped down a bit):  Reads and writes can be repeated without side-effects, and reads return the last value written.  In addition accesses can be misaligned and can be merged.


On Mon, May 18, 2020 at 5:35 PM Bill Huffman <huffman@...> wrote:

On 5/18/20 5:10 PM, David Kruckemyer wrote:


That sounds a bit like a performance counter to me, but it does raise an interesting question whether "idempotent" in the architectural sense is idempotent in a mathematical sense (i.e. operations are repeatable with the same result) or in a broader sense (e.g. inclusive of any side-effects even if the values at the location don't change).

I've always assumed the "non-idempotent" attribute meant that a read may not return the last value written or that repeated reads may not return the same value, not that the behavior included side-effects that are observable elsewhere. What is the consensus regarding this?


I've always assumed that it included any side-effects that mattered to the program.  It obviously does not include bringing the demise of a chip nearer with tiny amounts of electromigration.  I don't think it includes incrementing performance counters or shifting the results of predictors either.  Not sure how many things actually fit between your definition and mine.  Perhaps not many in real implementations.


Join { to automatically receive all group messages.