Re: cache block copies and clean operations
toggle quoted messageShow quoted text
I think some context is missing in your quotes. In particular, the bulleted items in section 2.2 are prefaced by the following (italics mine, your quotes in bold):
"A cache-block management instruction performs one of the following operations, relative to the copy of a given
cache block allocated in a given cache:
• An invalidate operation deallocates the copy of the cache block
• A clean operation performs a write transfer to another cache or to memory if the data in the copy of the
cache block have been modified by a store operation
• A flush operation atomically performs a clean operation followed by an invalidate operation"
So the operation definition in this section pertains to a single cache and describes the behavior of an individual cache. Later sections go on to expand the extent of operations across the set of coherent caches and define the behavior of multiple caches in aggregate. I suppose one way to address your concerns is to describe operations in plural for the operations on coherent caches.
Additionally, earlier in Section 2.2, the whole paragraph describes what "identifying a cache block" implies:
"A CBO instruction causes one or more operations to be performed on the cache blocks identified by the
instruction. In general, a CBO instruction may identify one or more cache blocks; however, in the initial set of
CMO extensions, CBO instructions identify a single cache block only."
Also, near the definition of a cache block in section 2.1:
"A cache block is identified by a physical address
corresponding to the underlying memory locations."
The point of this text is to say that CBO operations operate on a one cache block address, not a range, list, etc. of cache block addresses.
With respect to the definition of invalidate and clean operations, they are allowed to perform any operation within the bounds of normal cache behavior as long as the stated behaviors are performed. For example, an invalidate operation could perform a write transfer all the way to memory (assuming the line was previously modified by a store), but it must deallocate the line from all the relevant caches. We actually take advantage of this allowed behavior to map CBO.INVAL to a flush operation.
Finally, the whole point of the definitions is to allow implementations with non-coherent caches (those are the caches outside the set of coherent caches); however, as you point out, the system is required to implement protocol or memory access transactions that perform the proper operations all the way to "memory." In reality, "memory" just needs to be a point where all agents in the system are guaranteed to access the same values (a "point of coherence," if you will), which may mean that certain IP can only be utilized beyond that point. In short, an implementer has to choose the IP that satisfies the semantics of the instructions and deploy it appropriately.
Hope that clarifies things.
On Wed, May 11, 2022 at 9:31 AM Guy Lemieux <guy.lemieux@...> wrote:
The spec seems to have some ambiguity about cache block "copies", and