(no commit message)

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index dfabbaeef527b8dd120f093cdf238e18e9cd39d6..b3971fc94bd2c26049dd47506d1dbbff3310c42e 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -24,8 +24,8 @@ This document focuses on the encoding of [[SV|sv]], and assumes familiarity with
 It is also crucial to note that whilst this format augments instruction
 behaviour it works in conjunction with SVSTATE and other [[sv/sprs]].
 
-All bit numbers are in MSB0 form (the bits are numbered from 0 at the MSB
-on the left
+Except where explicitly stated all bit numbers remain as in the Power ISA:
+in MSB0 form (the bits are numbered from 0 at the MSB on the left
 and counting up as you move rightwards to the LSB end). All bit ranges are inclusive
 (so `4:6` means bits 4, 5, and 6, in MSB0 order).  **All register numbering and
 element numbering however is LSB0 ordering** which is a different convention used
@@ -49,20 +49,52 @@ interoperability expectations within certain environments.
 
 In the Upper Compliancy Levels the size of the GPR and FPR Register files are expanded
 from 32 to 128 entries, and the number of CR Fields expanded from CR0-CR7 to CR0-CR127.
+Memory access remains exactly the same: the effects of `MSR.LE` remain exactly the same,
+affecting **only** the Load and Store memory-register operation byte-order,
+and having nothing to do with the
+ordering of the contents of register files or register-register operations.
+
+Whilst the bits within the GPRs and FPRs are expected to be MSB0-ordered and for
+numbering to be sequentially incremental the element offset numbering is naturally
+**LSB0-sequentially-incrementing from zero not MSB0-incrementing.**  Expressed in
+MSB0-numbering SVP64 is unnecessarily complex to understand: subtractions from 63, 31,
+15 and 7 become a hostile minefield.  Therefore for the purposes of this section
+**LSB0 numbering is assumed** and it is up to the reader to translate to MSB0 numbering.
+
+The Canonical specification for how element-sequential numbering and element-width
+overrides is defined is expressed in the following c structure, assuming a Little-Endian
+system, and naturally using LSB0 numbering everywhere because the ANSI c specification
+is inherently LSB0:
 
 ```
     #pragma pack
     typedef union {
-        uint8_t  b[];
-        uint16_t s[];
-        uint32_t i[];
-        uint64_t l[];
+        uint8_t  b[]; // elwidth 8
+        uint16_t s[]; // elwidth 16
+        uint32_t i[]; // elwidth 32
+        uint64_t l[]; // elwidth 64
         uint8_t actual_bytes[8];
     } el_reg_t;
 
     elreg_t int_regfile[128];
 ```
 
+Example add operation implementation when elwidths are 64-bit:
+
+```
+ # add RT, RA,RB using the "uint64_t" union member, "l"
+ for i in range(VL):
+      int_regfile[RT].l[i] = int_regfile[RA].l[i] + int_regfile[RB].l[i]
+```
+
+However if elwidth overrides are set to 16 for both source and destination:
+
+```
+ # add RT, RA, RB using the "uint64_t" union member "s"
+ for i in range(VL):
+      int_regfile[RT].s[i] = int_regfile[RA].s[i] + int_regfile[RB].s[i]
+```
+
 Hardware Architectural note: to avoid a Read-Modify-Write at the register file it is
 strongly recommended to implement byte-level write-enable lines exactly as has been
 implemented in DRAM ICs for many decades. Additionally the predicate mask bit is advised