Incorporate Krste's feedback on Zimop chapter

1 files changed, 35 insertions, 10 deletions

diff --git a/src/zimop.adoc b/src/zimop.adoc
index 1d17686..79035e6 100644
--- a/src/zimop.adoc
+++ b/src/zimop.adoc
@@ -2,15 +2,15 @@
 == "Zimop" May-Be-Operations Extension, Version 0.1
 This chapter defines the "Zimop" extension, which introduces the concept of
 instructions that _may be operations_ (MOPs).  MOPs are initially defined to
-perform no useful operation and raise no exceptions, but might be redefined by
-later extensions to perform some other action.  The Zimop extension defines an
-encoding space for 40 MOPs.
+simply write zero to `x[rd]`, but are designed to be redefined by later
+extensions to perform some other action.
+The Zimop extension defines an encoding space for 40 MOPs.
 
 [NOTE]
 ====
 It is sometimes desirable to define instruction-set extensions whose
 instructions, rather than raising illegal instruction exceptions when the extension is
-not implemented, take no useful action.
+not implemented, take no useful action (beyond writing `x[rd]`).
 For example, programs with control-flow integrity checks can
 execute correctly on implementations without the corresponding extension,
 provided the checks are simply ignored.  Implementing these checks as MOPs
@@ -51,8 +51,9 @@ NOTE: These MOPs are defined to write zero to `x[rd]`, rather than performing
 no operation, to simplify instruction decoding and to allow testing the
 presence of features by branching on the zeroness of the result.
 
-The MOPs defined in the Zimop extension are not guaranteed to carry
-a syntactic dependency from `x[rs1]` or `x[rs2]` to `x[rd]`.
+The MOPs defined in the Zimop extension do not carry a syntactic dependency
+from `x[rs1]` or `x[rs2]` to `x[rd]`, though an extension that redefines the
+MOP may impose such a requirement.
 
 NOTE: Not carrying a syntactic dependence relieves straightforward
 implementations of reading `x[rs1]` and `x[rs2]`.
@@ -64,16 +65,40 @@ implementations of reading `x[rs1]` and `x[rs2]`.
 This section defines the "Zcmop" extension, which defines eight 16-bit MOP
 instructions named `c.mop.__n__`, where __n__ is an integer between 0 and 7,
 inclusive.  `c.mop.__n__` is encoded in the reserved encoding space
-corresponding to `c.lui x__m__, 0`, where __m__=2__n__+1.  These instructions
-are defined to not write any register. Their encoding allows future extensions
-to define them to read register `x[__m__]`.
+corresponding to `c.lui x__m__, 0`, where __m__=2__n__+1, as shown in Table
+<<tab:c-mop>>.
+Unlike the MOPs defined in the Zimop extension, the `c.mop.__n__` instructions
+are defined to _not_ write any register.
+Their encoding allows future extensions to define them to read register
+`x[__m__]`.
 
 include::images/wavedrom/c-mop.adoc[]
 [[c-mop]]
 
+NOTE: Very few suitable 16-bit encoding spaces exist.  This space was chosen
+because it already has unusual behavior with respect to the `rd`/`rs1`
+field--it encodes `c.addi16sp` when the field contains `x2`--and is
+therefore of lower value for most purposes.
+
+[[tab:c-mop]]
+.`c.mop.__n__` instruction encoding.
+
+|===
+|Mnemonic | Encoding           | Redefinable to read register
+
+|c.mop.0  | `0110000010000001` | `x1`
+|c.mop.1  | `0110000110000001` | `x3`
+|c.mop.2  | `0110001010000001` | `x5`
+|c.mop.3  | `0110001110000001` | `x7`
+|c.mop.4  | `0110010010000001` | `x9`
+|c.mop.5  | `0110010110000001` | `x11`
+|c.mop.6  | `0110011010000001` | `x13`
+|c.mop.7  | `0110011110000001` | `x15`
+|===
+
 NOTE: The recommended assembly syntax for `c.mop.__n__` is simply the nullary
 `c.mop.__n__`.  The possibly accessed register is implicitly `x__m__`.
 
 NOTE: The expectation is that each Zcmop instruction is equivalent to some
-Zimop instruction, but the choice of expansion (if any) is left to the
+Zimop instruction with `rd`=`x0`, but the choice of expansion (if any) is left to the
 extension that redefines the MOP.