Remove Zam; define misaligned atomicity granule PMA (#1206)

* Excise Zam extension

* Define the misaligned atomicity granule PMA

src/a-st-ext.adoc

@@ -369,7 +369,19 @@ is not naturally aligned, an address-misaligned exception or an
 access-fault exception will be generated. The access-fault exception can
 be generated for a memory access that would otherwise be able to
 complete except for the misalignment, if the misaligned access should
-not be emulated. The "Zam" extension, described in <<zam>>, relaxes this requirement and specifies the semantics of misaligned AMOs.
+not be emulated.
+
+The misaligned atomicity granule PMA, defined in Volume II of this manual,
+optionally relaxes this alignment requirement.
+If present, the misaligned atomicity granule PMA specifies the size
+of a misaligned atomicity granule, a power-of-two number of bytes.
+The misaligned atomicity granule PMA applies only to AMOs, loads and stores
+defined in the base ISAs, and loads and stores of no more than XLEN bits
+defined in the F, D, and Q extensions.
+For an instruction in that set, if all accessed bytes lie within the same
+misaligned atomicity granule, the instruction will not raise an exception for
+reasons of address alignment, and the instruction will give rise to only one
+memory operation for the purposes of RVWMO--i.e., it will execute atomically.
 
 The operations supported are swap, integer add, bitwise AND, bitwise OR,
 bitwise XOR, and signed and unsigned integer maximum and minimum.

src/colophon.adoc

@@ -35,7 +35,6 @@ h|Extension h|Version h|Status
 |*Zifencei* |*2.0* |*Ratified*
 |*Zihintpause* |*2.0* |*Ratified*
 |*Zihintntl* |*1.0* |*Ratified*
-|_Zam_ |_0.1_ |_Draft_
 |*Zfa* |*1.0* |*Ratified*
 |*Zfh* |*1.0* |*Ratified*
 |*Zfhmin* |*1.0* |*Ratified*
@@ -47,6 +46,11 @@ h|Extension h|Version h|Status
 |*Ztso* |*1.0* |*Ratified*
 |===
 
+The changes in this version of the document include:
+
+* The draft Zam extension has been removed, in favor of the
+definition of a misaligned atomicity granule PMA.
+
 [.big]*_Preface to Document Version 20191213-Base-Ratified_*
 
 This document describes the RISC-V unprivileged architecture.

src/machine.adoc

@@ -2587,39 +2587,37 @@ should provide alternative fall-back mechanisms used when lack of
 progress is detected.
 ====
 
-===== Alignment
-
-Memory regions that support aligned LR/SC or aligned AMOs might also
-support misaligned LR/SC or misaligned AMOs for some addresses and
-access widths. If, for a given address and access width, a misaligned
-LR/SC or AMO generates an address-misaligned exception, then _all_
-loads, stores, LRs/SCs, and AMOs using that address and access width
-must generate address-misaligned exceptions.
-
-[NOTE]
-====
-The standard "A" extension does not support misaligned AMOs or LR/SC
-pairs. Support for misaligned AMOs is provided by the standard "Zam"
-extension. Support for misaligned LR/SC sequences is not currently
-standardized, so LR and SC to misaligned addresses must raise an
-exception.
-
-Mandating that misaligned loads and stores raise address-misaligned
-exceptions wherever misaligned AMOs raise address-misaligned exceptions
-permits the emulation of misaligned AMOs in an M-mode trap handler. The
-handler guarantees atomicity by acquiring a global mutex and emulating
-the access within the critical section. Provided that the handler for
-misaligned loads and stores uses the same mutex, all accesses to a given
-address that use the same word size will be mutually atomic.
-====
-
+==== Misaligned Atomicity Granule PMA
+
+The misaligned atomicity granule PMA provides constrained support for
+misaligned AMOs.
+This PMA, if present, specifies the size of a _misaligned atomicity granule_,
+a power-of-two number of bytes.
+Specific supported values for this PMA are represented by MAG__NN__, e.g.,
+MAG16 indicates the misaligned atomicity granule is at least 16 bytes.
+
+The misaligned atomicity granule PMA applies only to AMOs, loads and stores
+defined in the base ISAs, and loads and stores of no more than MXLEN bits
+defined in the F, D, and Q extensions.
+For an instruction in that set, if all accessed bytes lie within the same
+misaligned atomicity granule, the instruction will not raise an exception for
+reasons of address alignment, and the instruction will give rise to only one
+memory operation for the purposes of RVWMO--i.e., it will execute atomically.
+
+If a misaligned AMO accesses a region that does not specify a misaligned
+atomicity granule PMA, or if not all accessed bytes lie within the same
+misaligned atomicity granule, then an exception is raised.
+For regular loads and stores that access such a region or for which not all
+accessed bytes lie within the same atomicity granule, then either an exception
+is raised, or the access proceeds but is not guaranteed to be atomic.
 Implementations may raise access-fault exceptions instead of
-address-misaligned exceptions for some misaligned accesses, indicating
-the instruction should not be emulated by a trap handler. If, for a
-given address and access width, all misaligned LRs/SCs and AMOs generate
-access-fault exceptions, then regular misaligned loads and stores using
-the same address and access width are not required to execute
-atomically.
+address-misaligned exceptions for some misaligned accesses, indicating the
+instruction should not be emulated by a trap handler.
+
+NOTE: LR/SC instructions are unaffected by this PMA and so always raise an
+exception when misaligned.  Vector memory accesses are also unaffected, so
+might execute non-atomically even when contained within a misaligned atomicity
+granule.
 
 ==== Memory-Ordering PMAs
 

src/mm-formal.adoc

@@ -1403,7 +1403,7 @@ _instruction_tree_; and
 ==== Limitations
 
 * The model covers user-level RV64I and RV64A. In particular, it does
-not support the misaligned atomics extension "Zam" or the total store
+not support the misaligned atomicity granule PMA or the total store
 ordering extension "Ztso". It should be trivial to adapt the model to
 RV32I/A and to the G, Q and C extensions, but we have never tried it.
 This will involve, mostly, writing Sail code for the instructions, with

src/naming.adoc

@@ -84,8 +84,8 @@ an alphabetical name and an optional version number. For example,
 
 The first letter following the "Z" conventionally indicates the most
 closely related alphabetical extension category, IMAFDQCVH. For the
-"Zam" extension for misaligned atomics, for example, the letter "a"
-indicates the extension is related to the "A" standard extension. If
+"Zfa" extension for additional floating-point instructions, for example, the letter "f"
+indicates the extension is related to the "F" standard extension. If
 multiple "Z" extensions are named, they should be ordered first by
 category, then alphabetically within a category—for example,
 "Zicsr_Zifencei_Zam".
@@ -192,8 +192,6 @@ e.g., RV32IMACV is legal, whereas RV32IMAVC is not.
 
 |Instruction-Fetch Fence |Zifencei |
 
-|Misaligned Atomics |Zam |A
-
 |Total Store Ordering |Ztso |
 
 3+|*Standard Supervisor-Level Extensions*

src/riscv-unprivileged.adoc

@@ -120,8 +120,6 @@ include::p-st-ext.adoc[]
 //p.tex
 include::v-st-ext.adoc[]
 //v.tex
-include::zam-st-ext.adoc[]
-//zam.tex
 include::zfinx.adoc[]
 //zfinx.tex
 include::zfa.adoc[]

src/rvwmo.adoc

@@ -20,10 +20,8 @@ base RISC-V ISA provides a FENCE instruction for this purpose, described
 in <<fence>>, while the atomics extension "A" additionally defines load-reserved/store-conditional and atomic read-modify-write instructions.
 (((atomics, misaligned)))
 
-The standard ISA extension for misaligned atomics "Zam"
-(<<zam>>) and the standard ISA extension for total
-store ordering "Ztso" (<<ztso>>) augment RVWMO
-with additional rules specific to those extensions.
+The standard ISA extension for total store ordering "Ztso" (<<ztso>>) augments
+RVWMO with additional rules specific to those extensions.
 
 The appendices to this specification provide both axiomatic and
 operational formalizations of the memory consistency model as well as
@@ -102,12 +100,13 @@ a set of component memory operations of any granularity. The memory
 operations generated by such instructions are not ordered with respect
 to each other in program order, but they are ordered normally with
 respect to the memory operations generated by preceding and subsequent
-instructions in program order. The atomics extension "A" does not
-require execution environments to support misaligned atomic instructions
-at all; however, if misaligned atomics are supported via the "Zam"
-extension, LRs, SCs, and AMOs may be decomposed subject to the
-constraints of the atomicity axiom for misaligned atomics, which is
-defined in <<zam>>.
+instructions in program order.
+The atomics extension "A" does not require execution environments to support
+misaligned atomic instructions at all.
+However, if misaligned atomics are supported via the misaligned atomicity
+granule PMA, then AMOs within an atomicity granule are not decomposed, nor are
+loads and stores defined in the base ISAs, nor are loads and stores of no more
+than XLEN bits defined in the F, D, and Q extensions.
 (((decomposition)))
 
 [NOTE]