clarify table

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index dfef6fc40ad76809e1f867cff7fc5914b48154db..4495d068d8c25dc9d968a3439e5f9dfea422cfa6 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -2,7 +2,7 @@
 
 * RFC Author: Luke Kenneth Casson Leighton.
 * RFC Contributors/Ideas: Brad Frey, Paul Mackerras
-* <https://git.openpower.foundation/isa/PowerISA/issues/64> 
+* <https://git.openpower.foundation/isa/PowerISA/issues/64>
   [[ls001/discussion]]
 
 This proposal is to extend the Power ISA with an Abstract RISC-Paradigm
@@ -30,11 +30,11 @@ processors that are competitive in the 3D GPU Audio Visual DSP EDGE IoT
 desktop chromebook netbook smartphone laptop markets, performance-leveraged
 by Simple-V.  Simple-V thus has to
 be accompanied by corresponding **Scalar** instructions that bring the
-**Scalar** Power ISA up-to-date.  These include IEEE754 
+**Scalar** Power ISA up-to-date.  These include IEEE754
 [Transcendentals](https://libre-soc.org/openpower/transcendentals/)
 [AV](https://libre-soc.org/openpower/sv/av_opcodes/)
 cryptographic
-[Biginteger](https://libre-soc.org/openpower/sv/biginteger/) and 
+[Biginteger](https://libre-soc.org/openpower/sv/biginteger/) and
 [bitmanipulation](https://libre-soc.org/openpower/sv/bitmanip)
 operations that ARM
 Intel AMD and many other ISAs have been adding over the past 12 years
@@ -334,32 +334,33 @@ is based loosely around Public v3.1 EXT001 Encoding. [^ext001]
 * **old-suffix** - the EXT000 to EXT063 32-bit Major opcodes of Power ISA 3.0
 * **new scalar-only** - a **new** Major Opcode area **exclusively**
   for Scalar-only instructions that shall **never** be Prefixed by SVP64
-  (RESERVED2 EXT300-EXT363) 
+  (RESERVED2 EXT300-EXT363)
 * **new-suffix** - a **new** Major Opcode area (RESERVED1 EXT200-EXT263)
   that **may** be Prefixed by SVP64 and SVP64Single
 * **0000** - all 24 bits bits 8-31 are zero (0x000000)
 * **!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](https://bugs.libre-soc.org/show_bug.cgi?id=905))
-  Encoding that is near-identical to SVP64
-  except that it is not a Vector Operation (equivalent to hard-coded VL=1
-  at all times). Predication is permitted, Element-width-overrides is
-  permitted, Saturation is permitted. SVP64Single is a **scalar** augmentation
-  of its suffix.
+  *Scalar* Encoding that is near-identical to SVP64
+  except that it is equivalent to hard-coded VL=1
+  at all times. Predication is permitted, Element-width-overrides is
+  permitted, Saturation is permitted.
 * **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation
   Augmentation of suffixes.
 
-For the needs identified by Libre-SOC's team, one of the `RESERVED` spaces *needs* allocation to new POs, the other does not. [^only2]
+For the needs identified by Libre-SOC's team, the `RESERVED2` space *needs*
+allocation to new POs, `RESERVED1` does not.[^only2]
 
 |          | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1)  |
 |----------|---------------------------|---------------------------|------------------|
 |new bit6=0| `RESERVED1`:{EXT200-063}  | SVP64-Single:{EXT200-263} | SVP64:{EXT200-263} |
 |old bit6=1| `RESERVED2`:{EXT300-363}  | SVP64-Single:{EXT000-063}   | SVP64:{EXT000-063}   |
 
-* **`RESERVED2`:{EXT300-363}** (not strictly necessary to be added) is not and **cannot** ever be Vectorised or
-  Augmented by Simple-V or any future Simple-V Scheme.
-  it is a pure **Scalar-only** PO Group. It may remain `RESERVED`.
-* **`RESERVED1`:{EXT200-263}** is also a Scalar-only new set of 64 Major
+* **`RESERVED2`:{EXT300-363}** (not strictly necessary to be added) is not
+  and **cannot** ever be Vectorised or Augmented by Simple-V or any future
+  Simple-V Scheme.
+  it is a pure **Scalar-only** word-length PO Group. It may remain `RESERVED`.
+* **`RESERVED1`:{EXT200-263}** is also a new set of 64 word-length Major
   Opcodes.
   These opcodes do not *need* to be Simple-V-Augmented
   *but the option to do so exists* should an Implementor choose to do so.
@@ -382,7 +383,7 @@ For the needs identified by Libre-SOC's team, one of the `RESERVED` spaces *need
   32-bit scalar versions.
 
 Limitations of this scheme is that new 32-bit Scalar operations have to have
-a 32-bit "escape-sequence" in front of them. If commonly-used this could
+a 32-bit "prefix pattern" in front of them. If commonly-used this could
 increase binary size. Thus the Encodings EXT300-363 and EXT200-263 should
 only be allocated for less-popular operations.  However the scheme does
 have the strong advantage of *tripling* the available number of Major