(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index b8a862bab6bd65a9a40e2b40c3be55f8276c9f8b..2b1a57aa97a5f0dd21609992050c3ace69a87464 100644 (file)
--- 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