From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Mon, 3 Apr 2023 14:16:24 +0000 (+0100)
Subject: mention how same contents get viewed in 32-bit elements
X-Git-Tag: opf_rfc_ls012_v1~152
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=22af78030342e9b90be10046fca0e5202d7d803c;p=libreriscv.git

mention how same contents get viewed in 32-bit elements
---

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 62adce7be..1a3e8676c 100644
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -271,6 +271,29 @@ as simultaneous non-overlapping Register File writes, to achieve High
 Performance designs.  Overall it helps to think of the register files
 as being much more akin to a byte-level-addressable SRAM.
 
+If the 16-bit operation were to be followed up with a 32-bit Vectorised
+Operation, the exact same contents would be viewed as follows:
+
+```
+    | MSB0:  | 0:31                 | 32:63                |
+    | LSB0:  | 63:32                | 31:0                 |
+    |--------|----------------------|----------------------|
+    | GPR(0) | same                 | same                 |
+    | GPR(1) | (result3 || result2) | (result1 || result0) |
+    | GPR(2) | same                 | (same    || result4) |
+    | GPR(3) | same                 | same                 |
+    | ...    | ...                  | ...                  |
+    | ...    | ...                  | ...                  |
+```
+
+In other words, this perspective really is no different from the situation
+where the actual Register File is treated as a byte-level-addressable
+Little-Endian-addressed SRAM.  Note that this perspective does **not**
+involve `MSR.LE` in any way shape or form because `MSR.LE` is directly
+in control of the Memory-to-Register byte-ordering. This section is
+exclusively about how to correctly perceive Simple-V-Augmented **Register**
+Files.
+
 **Comparative equivalent using VSR registers**
 
 For a comparative data point the VSR Registers may be expressed in the