(no commit message)

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
index c6661174323853ad35a42b6b4c5897358d85cffe..375ff81b41116b162eab74cb7847b09bfded3a4f 100644 (file)
--- a/openpower/sv/cr_ops.mdwn
+++ b/openpower/sv/cr_ops.mdwn
@@ -16,7 +16,8 @@ width (which is clearly meaningless for a 4-bit
 collation of Conditions, EQ LT GE SO). Likewise, arithmetic saturation
 (an important part of Arithmetic SVP64)
 has no meaning. Additionally, extra modes are required that only make
-sense for Vectorised CR Operations. Consequently an alternative Mode Format is required.
+sense for Vectorised CR Operations. Consequently an alternative Mode Format is required, and given that elwidths are meaningless for CR Fields
+the bits in SVP64 `RM` may be used for other purposes.
 
 This alternative mapping **only** applies to instructions that **only**
 reference a CR Field or CR bit as the sole exclusive result. This section
@@ -66,6 +67,16 @@ predicates may themselves be Condition Registers it can be seen that
 there could potentially be up to **six** CR Fields involved in
 the execution of Predicate-result Mode.
 
+A reminder that, just as with other SVP64 Modes, unlike v3.1 64 bit
+Prefixing there are insufficient bits spare in the prefix to mark
+the type. Therefore, the SVP64 Mode must be identified by first
+decoding the suffix (the 32 bit scalar operation), and, once
+the instruction is identified (cmpi, mfcr, crweird)
+only then may the type of SVP64 Mode (normal, branch, LDST, CR 3-bit
+or CR 5-bit) be decoded.
+
+# Format
+
 SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations:
 
 | 4 | 5 | 19-20 |  21 | 22   23 |  description     |