(no commit message)

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index 32b5ad4eb57b1ca6dfa6afb7d9011fafc48f4089..f2d47701cb381bba4611f5550b0c66f3cb84eb42 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -25,7 +25,7 @@ Subsystem" similar to the 5 decades-old Zilog Z80 `LDIR` instruction and to the
 Prefix instruction.  More advanced features are similar to the Z80
 `CPIR` instruction. If viewed one-dimensionally as an actual Vector ISA it introduces
 over 1.5 million 64-bit Vector instructions.  SVP64, the instruction
-format, is therefore best viewed as an orthogonal RISC-paradigm "Prefixing"
+format used by Simple-V, is therefore best viewed as an orthogonal RISC-paradigm "Prefixing"
 subsystem instead.
 
 Except where explicitly stated all bit numbers remain as in the rest of
@@ -135,7 +135,8 @@ MSB0 ordering).
 When exclusively using MSB0-numbering, SVP64
 becomes unnecessarily complex to both express and subsequently understand:
 the required conditional subtractions from 63,
-31, 15 and 7 unfortunately become a hostile minefield, obscuring both
+31, 15 and 7 needed to express the fact that elements are LSB0-sequential
+unfortunately become a hostile minefield, obscuring both
 intent and meaning. Therefore for the
 purposes of this section the more natural **LSB0 numbering is assumed**
 and it is left to the reader to translate to MSB0 numbering.
@@ -208,7 +209,7 @@ Performance designs.
 ## Scalar Identity Behaviour
 
 SVP64 is designed so that when the prefix is all zeros, and
- VL=1, no effect or
+VL=1, no effect or
 influence occurs (no augmentation) such that all standard Power ISA
 v3.0/v3 1 instructions covered by the prefix are "unaltered". This
 is termed `scalar identity behaviour` (based on the mathematical
@@ -305,11 +306,11 @@ new 64-bit encoding space, alongside EXT1xx.
 
 | 0-5 | 6 | 7 | 8-31  | 32| Description                        |
 |-----|---|---|-------|---|------------------------------------|
-| PO  | 0 | x | xxxx  | 0 | EXT200-231 or `RESERVED2` (56-bit) |
+| PO  | 0 | x | xxxx  | 0 | `RESERVED2` (56-bit) |
 | PO  | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
 | PO  | 0 | 0 | 0000  | 1 | Scalar EXT232-263               |
 | PO  | 0 | 1 | nnnn  | 1 | SVP64:EXT232-263     |
-| PO  | 1 | 0 | 0000  | x | EXT300-363 or `RESERVED1` (32-bit) |
+| PO  | 1 | 0 | 0000  | x | `RESERVED1` (32-bit) |
 | PO  | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
 | PO  | 1 | 1 | nnnn  | n | SVP64:EXT000-063       |
 
@@ -320,9 +321,9 @@ can be zero (termed `scalar identity behaviour`). This
 prohibition allows SVP64Single to share its
 Encoding space with Scalar Ext232-263 and Scalar EXT300-363.
 
-Also that RESERVED1 and 2 are given *tentative* naming EXT200-231 and
-EXT300-363 respectively, in reality they are completely unused and
-future use may allocate entirely different naming.
+Also that RESERVED1 and 2 are candidates for future Major opcode
+areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
+they may equally be allocated entirely differently.
 
 *Architectural Resource Allocation Note: **under no circumstances** must
 different Defined Words be allocated within any `EXT{z}` prefixed
@@ -333,7 +334,8 @@ being RESERVED if UnVectoriseable) or not be allocated at all.
 This is required as an inviolate hard rule governing Primary Opcode 9
 that may not be revoked under any circumstances. A useful way to think
 of this is that the Prefix Encoding is, like the 8086 REP instruction,
-an independent 32-bit Defined Word.*
+an independent 32-bit Defined Word. The only semi-exceptions are
+the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
 
 Ecoding spaces and their potential are illustrated: