From: lkcl <lkcl@web>
Date: Mon, 3 Apr 2023 23:40:16 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls012_v1~149
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=115cdac1494d1e748b48c43206a3b559fe3421f3;p=libreriscv.git

---

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 7b7dce40e..7193a586b 100644
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -255,8 +255,8 @@ be as follows.  For clarity in the table below:
     | ...    | ...     | ...     | ...     | ...     |
 ```
 
-Note that the upper 48 bits of GPR(1) would **not** be modified because
-the example has VL=5.  Thus on "wrapping" - sequential progression from
+Note that the upper 48 bits of GPR(2) would **not** be modified due to
+the example having VL=5.  Thus on "wrapping" - sequential progression from
 GPR(1) into GPR(2) - the 5th result modifies
 **only** the bottom 16 LSBs of GPR(1).
 
@@ -291,7 +291,7 @@ Operation, the exact same contents would be viewed as follows:
 ```
 
 In other words, this perspective really is no different from the situation
-where the actual Register File is treated as a byte-level-addressable
+where the actual Register File is treated as an Industry-standard 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