From: lkcl <lkcl@web>
Date: Fri, 17 Sep 2021 14:40:25 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: DRAFT_SVP64_0_1~91
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=17987121fc215e42188c41dd139dfa7297f31ec0;p=libreriscv.git

---

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index c402326cb..217ceba0a 100644
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -313,18 +313,21 @@ are stored "as usual" exactly as all other SVP64 Rc=1 operations.
 
 Note that when SVM is clear and SUBVL!=1 the sub-elements are
 *independent*, i.e. they are mapreduced per *sub-element* as a result.
-illustration with a vec2:
+illustration with a vec2, assuming RA==RT, e.g `sv.add/mr/vec2 r4, r4, r16`
 
-    result.x = op(iregs[RA].x, iregs[RA+1].x)
-    result.y = op(iregs[RA].y, iregs[RA+1].y)
-    for i in range(2, VL):
-        result.x = op(result.x, iregs[RA+i].x)
-        result.y = op(result.y, iregs[RA+i].y)
+    for i in range(0, VL):
+        # RA==RT in the instruction. does not have to be
+        iregs[RT].x = op(iregs[RT].x, iregs[RB+i].x)
+        iregs[RT].y = op(iregs[RT].y, iregs[RB+i].y)
 
-Note here that Rc=1 does not make sense when SVM is clear and SUBVL!=1.
+Thus logically there is nothing special or unanticipated about
+`SVM=0`: it is expected behaviour according to standard SVP64
+Sub-Vector rules.
 
-When SVM is set and SUBVL!=1, another variant is enabled: horizontal
-subvector mode.  Example for a vec3:
+By contrast, when SVM is set and SUBVL!=1, a Horizontal
+Subvector mode is enabled, which behaves very much more
+like a traditional Vector Processor Reduction instruction.
+Example for a vec3:
 
     for i in range(VL):
         result = iregs[RA+i].x