(no commit message)

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index b3971fc94bd2c26049dd47506d1dbbff3310c42e..83de11496754181631d6815831431076e45f2444 100644 (file)
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -49,16 +49,18 @@ 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
+affecting as they already do and remain to **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-sequentially-incrementing from zero not MSB0-incrementing.**  Expressed exclusively in
+MSB0-numbering, SVP64 is unnecessarily complex to understand: the required
+subtractions from 63, 31, 15 and 7 unfortunately become a hostile minefield.
+Therefore for the purposes of this section the more natural
 **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
@@ -77,6 +79,12 @@ is inherently LSB0:
     } el_reg_t;
 
     elreg_t int_regfile[128];
+
+    void get_register_element(el_reg_t* el, int gpr, int element, int width) {
+        switch (width) {
+            case 64: el->l = int_regfile[gpr].l[element];
+        }
+    }
 ```
 
 Example add operation implementation when elwidths are 64-bit: