From: lkcl <lkcl@web>
Date: Sat, 24 Sep 2022 20:29:37 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~311
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ebf3891935d9d51d402cafca770700a34f797f2f;p=libreriscv.git

---

diff --git a/openpower/sv/overview/discussion.mdwn b/openpower/sv/overview/discussion.mdwn
index b4287ba28..d9d001235 100644
--- a/openpower/sv/overview/discussion.mdwn
+++ b/openpower/sv/overview/discussion.mdwn
@@ -16,14 +16,18 @@ possibility of MSB0 numbering being potentially applicable to:
 * register numbers
 * element numbers
 
+In other words, when communicating in a Specification there are **four**
+possible areas for confusion.
+
 Then there is the completely separate issue of whether:
 
 * Memory should be the sole location where LE/BE byteswapping should
-  be applicable, Architecturally
-* Both the register file *and* Memory are, both, Architecturally,
-  LE/BE reorderable and thus **direct and explicit** control over
+  be applicable, Architecturally.
+* Both the register file *and* Memory should both be, Architecturally,
+  LE/BE reorderable with the implication that
+  **direct and explicit** control over
   reordering over Memory **and the bytes inside regfile data**
-  is provided at the ISA Level.
+  needs provided at the ISA Level.
 
 Simple-V has made the decision that providing programmers with explicit
 control over the byte-ordering when data is transferred in and out of
@@ -37,6 +41,15 @@ that how the Hardware is implemented is entirely down to the implementor,
 but that as far as *software* running on that hardware is concerned,
 "Architecturally" everything appears as described.
 
+In other words once loaded, software may be written that
+considers arithmetic values in a uniform environment regardless
+of whether `MSR.BE`, which is considered to affect **Memory only**,
+is set or unset.  If byteswapping is required it may be performed
+explicitly, by either loading to/from Memory or by performing Simple-V
+byte-level element-width override "Reverse Gear" element walking,
+or using Matrix REMAP with Dimensional Inversion, or any number of
+methods.
+
 In the overview page is this:
 
        | byte0 | byte1 | byte2 | byte3 | byte4 | byte5 | byte6 | byte7 |