mention how same contents get viewed in 32-bit elements

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 62adce7beeaa2663802b9841a36688216925dbc9..1a3e8676c19a449441d076c98a10ec4a18033935 100644 (file)
--- 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