From: lkcl <lkcl@web>
Date: Wed, 29 Mar 2023 21:45:59 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls012_v1~225
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d9d088b431372e176ffe09b17cd9e08286835f7a;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls010.mdwn b/openpower/sv/rfc/ls010.mdwn
index c93fb26be..b1320a732 100644
--- a/openpower/sv/rfc/ls010.mdwn
+++ b/openpower/sv/rfc/ls010.mdwn
@@ -124,12 +124,18 @@ To be absolutely clear:
     element numbering are expressed or implied
 ```
 
-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.**  When exclusively using MSB0-numbering, SVP64
+Element offset
+numbering is naturally **LSB0-sequentially-incrementing from zero, not
+MSB0-incrementing** including when element-width overrides are used,
+at which point the elements progress through each register
+sequentially from the LSB end
+(confusingly numbered the highest in MSB0 ordering) and progress
+incrementally to the MSB end (confusingly numbered the lowest in
+MSB0 ordering).
+
+When exclusively using MSB0-numbering, SVP64
 becomes unnecessarily complex to both express and subsequently understand:
-the required subtractions from 63,
+the required conditional subtractions from 63,
 31, 15 and 7 unfortunately become a hostile minefield, obscuring both
 intent and meaning. Therefore for the
 purposes of this section the more natural **LSB0 numbering is assumed**