From 115cdac1494d1e748b48c43206a3b559fe3421f3 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 4 Apr 2023 00:40:16 +0100 Subject: [PATCH] --- openpower/sv/svp64.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 -- 2.30.2