From: lkcl <lkcl@web>
Date: Wed, 17 Aug 2022 13:48:56 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~841
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=7399de0ca8f2690061609cc74158c16e37373972;p=libreriscv.git

---

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index b8a862bab..2b1a57aa9 100644
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -578,15 +578,20 @@ comes when Pack/Unpack are enabled, and it is really important
 to be aware how the Arrays of vec2/3/4 become re-ordered
 *and swizzled at the same time*.
 
-Pack/Unpack applies to 
-[[sv/mv.vec]] as well however the uniform relationship and
-the fact that the source and destination subvector length
-must be the same (vec2/3/4) makes things slightly easier to
-understand.  The main thing to keep in mind about Pack/Unpack
+Pack/Unpack started out as 
+[[sv/mv.vec]] but became its own distinct Mode over time.
+The main thing to keep in mind about Pack/Unpack
 is that it engages a swap of the ordering of the VL-SUBVL
 nested for-loops, in exactly the same way that Matrix REMAP
-can do.  When Pack or Unpack is enabled it is the SUBVL for-loop
-that becomes outermost.
+can do.
+When Pack or Unpack is enabled it is the SUBVL for-loop
+that becomes outermost.  A bit of thought shows that this is
+a 2D "Transpose" where Dimension X is VL and Dimension Y is SUBVL.
+However *both* source *and* destination may be independently
+"Transposed", which makes no sense at all until the fact that
+Swizzle can have a *different SUBVL* is taken into account.
+
+Basically Pack/Unpack 
 
 # No Scalar GPR Move