From: lkcl <lkcl@web>
Date: Sun, 25 Sep 2022 04:03:22 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~290
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=78aab1b4893c1dadf317fa17dc551cfb1e0c2a82;p=libreriscv.git

---

diff --git a/openpower/sv/overview/discussion.mdwn b/openpower/sv/overview/discussion.mdwn
index 8af509b4e..484eefda3 100644
--- a/openpower/sv/overview/discussion.mdwn
+++ b/openpower/sv/overview/discussion.mdwn
@@ -199,8 +199,9 @@ asuming a Little-Endian system, in the c programming language:
     elreg_t int_regfile[128];
 
 Where things become complicated is how to transliterate the above into
-MSB0 numbering, which significantly harms understanding and thus requires
-very careful, comprehensive and explicit coverage.
+MSB0 numbering, which significantly harms understanding as to how
+to clearly access elememts within the regfile, and thus requires
+very careful an comprehensive and explanation.
 We start with some definitions:
 
 * bit-ordering below is in MSB0 order, prefix "b"
@@ -216,7 +217,7 @@ Vector ISAs would require numbering element zero to be
 complete incomprehensibility.  Likewise the fact that registers
 are sequentially and serially aliases to the same underlying
 byte-addressable Memory, the register numbering must likewise
-be LSB0-ordered.  bit- and byte- numbering in MSB0 is not done
+be LSB0-ordered. The choice of bit- and byte- numbering in MSB0 is not done
 to increase understanding: it is done to match the precedent set
 when the Power ISA was first developed, over 25 years ago.
 
@@ -319,24 +320,38 @@ is as follows:
     |             r0.i[1]                         r0.i[1]              |
     |                            r0.l[0]                               |
 
-It is however just as critical to note that the following are also identical,
-where `r0=GPR(0)` and `r1=GPR(1)`:
+It is however just as critical to note that the following are also
+aliases, where `r0=GPR(0)` and `r1=GPR(1)`:
 
-    | B0     | B1    | B2    | B3    | B4    |    B5 |    B6 |    B7   |
+    | B0     | B1    | B2    | B3    | B4    |   B5  |   B6  |    B7   |
+    | B8     | B9    | B10   | B11   | B12   |   B13 |   B14 |    B15  |
     |        H0      |      H1       |      H2       |      H3         |
+    |        H4      |      H5       |      H6       |      H7         |
     |                W0              |               W1                |
+    |                W2              |               W3                |
     |                                D0                                |
+    |                                D1                                |
     |     r0.s[7]        r0.s[6]         r0.s[5]         r0.s[4]       |
     |     r1.s[3]        r1.s[2]         r1.s[1]         r1.s[0]       |
     |             r0.i[3]                         r0.i[2]              |
-    |             r1.i[1]                         r1.i[1]              |
+    |             r1.i[1]                         r1.i[0]              |
     |                            r0.l[1]                               |
     |                            r1.l[0]                               |
 
 These "aliases" which extend fully for all elements
 e0 onwards and all registers r0 onwards are down to
 the **intentionally-defined** overlaps in the canonical
-definition from the c union.  It can also be clearly seen
+definition from the LE-organised packed c union.
+
+If the element aliases were defined in MSB0 ordering then
+the sequential progression through elements so numbered VL-1 to 0
+would not only be in the opposite natural order from the loop
+sequence numbering expected to any computer program, but worse
+than that it would be on to of
+the already-complex half-word ordering, `H3 H2 H1 H0 H7 H6 H5 H4...`
+and word-ordering `W1 W0 W3 W2 W5 W4 W7 W6...`.
+
+Thus it can also be clearly seen
 why LSB0-numbering for elements and registers was picked
 because it would be near-possible to explain the overlapping
 when Scalability (VL, MAXVL) is introduced.