From: lkcl <lkcl@web>
Date: Fri, 19 Aug 2022 00:38:51 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~836
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6b80812f4d33fc05426539463ca3b35afbab132e;p=libreriscv.git

---

diff --git a/openpower/sv/mv.vec.mdwn b/openpower/sv/mv.vec.mdwn
index 9c510ee6c..095348d88 100644
--- a/openpower/sv/mv.vec.mdwn
+++ b/openpower/sv/mv.vec.mdwn
@@ -12,8 +12,7 @@ with pressure on the Scalar 32-bit opcode space it is more appropriate to
 compromise by adding required capability in SVP64 on top of a
 base pre-existing Scalar mv instruction.  [[sv/mv.swizzle]] is sufficiently
 unusual to justify a base Scalar 32-bit instruction but pack/unpack is not.
-Both may benefit from a use of the `RM.EXTRA` field to provide an
-additional mode, that may be applied to vec2/3/4.
+What, ultimately, was decided, was to make Pack/Unpack an `SVP64.RM` Mode.
 
 # REMAP concept for pack/unpack
 
@@ -73,9 +72,7 @@ room within the reserved bits of `svremap` as well.
 
 # RM Pack/unpack
 
-Also used on [[sv/mv.swizzle]] 
-
-`RM-2P-1S1D-PU` Mode, described in [[svp64/appendix]]
-is applicable to all mv operations
-(fmv etc) and to Indexed LD/ST.
-
+Described in [[svp64/appendix]] the Pack/Unpack Modes allow selective
+Transposition of Sub-vector elements, on both source and destination.
+[[sv/mv.swizzle]] is unique in that the Subvector length may be different
+for source and destination.