(no commit message)

diff --git a/openpower/sv/mv.vec.mdwn b/openpower/sv/mv.vec.mdwn
index ac7dec62b1a2b11e7ae1537eca228882c18af934..de40ddf0a8caa4371555e1051e77a500e9c7f003 100644 (file)
--- a/openpower/sv/mv.vec.mdwn
+++ b/openpower/sv/mv.vec.mdwn
@@ -92,5 +92,49 @@ mv.zip, RA!=0, RB!=0
 # REMAP concept for pack/unpack
 
 It may be possible to use one standard mv instruction to perform packing
-and unpacking. At the very least a predicate mask potentially can
+and unpacking: Matrix allows for both reordering and offsets. At the very least a predicate mask potentially can
 be used.
+
+* If a single src-dest mv is used, then it potentially requires
+  two separate REMAP and two separate sv.mvs: remap-even, sv.mv,
+  remap-odd, sv.mv
+* If adding twin-src and twin-dest that is a lot of instructions,
+  particularly if triple is added as well. FPR mv, GPR mv
+* Unless twin or triple is added, how is it possible to determine
+  the extra register(s) to be merged (or split)?
+
+How about instead relying on the implicit RS=MAXVL+RT trick and
+extending that to RS=MAXVL+RA as a source?  One spare bit in the
+EXTRA RM area says whether the sv.mv is a pack (RS-as-src=RA+MAXVL)
+or unpack (RS-as-dest=RT+MAXVL)
+
+Alternatively, given that Matrix is up to 3 Dimensions, not even
+be concerned about RS, just simply use one of those dimensions to
+span the packing:
+
+Example 1:
+
+* RA set to linear
+* RT set to YX, ydim=2, xdim=4
+* VL=MAXVL=8
+
+    | RA | (0 1) (2 3) (4 5) (6 7) |
+    | RT |   0 2 4 8     1 3 5 7   |
+
+This results in a 2-element "unpack"
+
+Example 2:
+
+* RT set to linear
+* RT set to YX, ydim=3, xdim=3
+* VL=MAXVL=9
+
+    | RA |  0 1 2   3 4 5   6 7 8  |
+    | RT | (0 3 6) (1 4 7) (2 5 8) |
+
+This results in a 3-element "pack"
+
+Both examples become particularly fun when Twin Predication is thrown
+into the mix.
+
+