amention not SVP64-Reserved

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index ed5c6725ab9ea9802e51700adc40050806557412..ba839a08119df5e88838d701850722a2d1944fbd 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -313,7 +313,7 @@ Scheme.
   RESERVED1 EXT200-EXT263 and
   RESERVED2 EXT300-EXT363
 * **0000** - all 24 bits bits 8-31 are zero (0x000000)
-* **!zero** - bits 8-31 may be any value *other* than zero
+* **!zero** - bits 8-31 may be any value *other* than zero (0x000001-0xffffff)
 * **nnnn** - bits 8-31 may be any value in the range 0x000000 to 0xffffff
 * **SVP64Single** - a (TBD) Encoding that is near-identical to SVP64
   except that it is not a Vector Operation (equivalent to hard-coded VL=1
@@ -323,9 +323,9 @@ Scheme.
 * **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation
   Augmentation of suffixes.
 
-(*For completeness, we recall that EXT100 to EXT163 is the numbering for
+(*Recall that EXT100 to EXT163 is for
 Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which,
-in Section 1.6.3, we note that bit 6 is set to 1.  This concept is where
+from Section 1.6.3, bit 6 is set to 1.  This concept is where
 the above scheme originated. Section 1.6.3 uses the term "defined word"
 to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed
 to create the new numbering EXT100-EXT163, respectively*)
@@ -371,7 +371,8 @@ have the strong advantage of *tripling* the available number of Major
 Opcodes in the Power ISA, caveat being that care on allocation is needed
 because EXT200-EXT263 may be SVP64-Augmented whilst EXT300-EXT363 may **not**.
 The issues of allocation for bitmanip etc. from Libre-SOC is therefore
-overwhelmingly made moot.
+overwhelmingly made moot. The only downside is that there is no
+`SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR).
 
 \newpage{}
 # Use cases