Update PMP spec to use "memory operation"

This part of the spec was written before the RVWMO section which introduced the "memory operation" nomenclature.

This updates the section to talk about memory operations instead of memory accesses.

I also reworked the text about CMOs and PMPs because it didn't quite make sense - the access size is irrelevant for PMPs; it's the memory operation size that matters, and that can be anything for CMOs since they are allowed to be decomposed.

Author: Timmmm

Diff for: src/cmo.adoc

@@ -337,8 +337,16 @@ _This specification assumes that the above constraints will typically be met for
 main memory regions and may be met for certain I/O regions._
 ====
 
-Additionally, for the purposes of PMP and PMA checks, the access size of a CMO
-instruction equals the size of the cache block accessed by the instruction.
+[NOTE]
+====
+The access size for CMO instructions is equal to the size of the cache
+block, however in some cases that access can be decomposed into multiple
+memory operations. PMP checks are applied to each memory operation
+independently. For example a 64-byte *cbo.zero* that spans two 32-byte PMP
+regions would succeed if it was decomposed into two 32-byte memory operations
+(and the PMP access control bits are the same in both regions), but if
+performed as a single 64-byte memory operation it would cause an access fault.
+====
 
 The Zicboz extension introduces an additional supported access type PMA for
 cache-block zero instructions. Main memory regions are required to support

Diff for: src/machine.adoc

@@ -3233,47 +3233,49 @@ R/W/X permissions apply only to S and U modes.
 
 ===== Priority and Matching Logic
 
+On some implementations, misaligned loads, stores, and instruction
+fetches may be decomposed into multiple memory operations, some of which may
+succeed before an access-fault exception occurs, as described in the RVWMO
+specification. PMP checking is performed on each memory operation independently.
+In particular, a portion of a misaligned store that passes
+the PMP check may become visible, even if another portion fails the PMP check.
+The same behavior may manifest for stores wider than XLEN bits (e.g., the
+FSD instruction in RV32D), even when the store address is naturally aligned.
+
 PMP entries are statically prioritized. The lowest-numbered PMP entry
-that matches any byte of an access determines whether that access
-succeeds or fails. The matching PMP entry must match all bytes of an
-access, or the access fails, irrespective of the L, R, W, and X bits.
+that matches any byte of a memory operation determines whether that operation
+succeeds or fails. The matching PMP entry must match all bytes of a memory
+operation, or the operation fails, irrespective of the L, R, W, and X bits.
 For example, if a PMP entry is configured to match the four-byte range
 `0xC`–`0xF`, then an 8-byte access to the range `0x8`–`0xF` will fail,
 assuming that PMP entry is the highest-priority entry that matches those
 addresses.
 
-If a PMP entry matches all bytes of an access, then the L, R, W, and X
-bits determine whether the access succeeds or fails. If the L bit is
-clear and the privilege mode of the access is M, the access succeeds.
+If a PMP entry matches all bytes of a memory operation, then the L, R, W, and X
+bits determine whether the operation succeeds or fails. If the L bit is
+clear and the privilege mode of the access is M, the operation succeeds.
 Otherwise, if the L bit is set or the privilege mode of the access is S
-or U, then the access succeeds only if the R, W, or X bit corresponding
+or U, then the operation succeeds only if the R, W, or X bit corresponding
 to the access type is set.
 
-If no PMP entry matches an M-mode access, the access succeeds. If no PMP
-entry matches an S-mode or U-mode access, but at least one PMP entry is
-implemented, the access fails.
+If no PMP entry matches an M-mode memory operation, the operation succeeds.
+If no PMP entry matches an S-mode or U-mode memory operation, but at least
+one PMP entry is implemented, the operation fails.
 
 [NOTE]
 ====
 If at least one PMP entry is implemented, but all PMP entries’ A fields
 are set to OFF, then all S-mode and U-mode memory accesses will fail.
 ====
 
-Failed accesses generate an instruction, load, or store access-fault
+Failed memory operations generate an instruction, load, or store access-fault
 exception. Note that a single instruction may generate multiple
-accesses, which may not be mutually atomic. An access-fault exception is
-generated if at least one access generated by an instruction fails,
-though other accesses generated by that instruction may succeed with
+memory operations, which may not be mutually atomic. An access-fault exception
+is generated if at least one memory operation generated by an instruction fails,
+though other memory operations generated by that instruction may succeed with
 visible side effects. Notably, instructions that reference virtual
-memory are decomposed into multiple accesses.
+memory are decomposed into multiple memory operations.
 
-On some implementations, misaligned loads, stores, and instruction
-fetches may also be decomposed into multiple accesses, some of which may
-succeed before an access-fault exception occurs. In particular, a
-portion of a misaligned store that passes the PMP check may become
-visible, even if another portion fails the PMP check. The same behavior
-may manifest for stores wider than XLEN bits (e.g., the FSD instruction
-in RV32D), even when the store address is naturally aligned.
 
 [[pmp-vmem]]
 ==== Physical Memory Protection and Paging