From: lkcl <lkcl@web>
Date: Sat, 11 Jun 2022 18:06:07 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~1846
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=2abc2e973396548e9a8124b07dcb324893453626;p=libreriscv.git

---

diff --git a/openpower/sv/mv.vec.mdwn b/openpower/sv/mv.vec.mdwn
index 87464f572..ec398bcb8 100644
--- a/openpower/sv/mv.vec.mdwn
+++ b/openpower/sv/mv.vec.mdwn
@@ -7,7 +7,7 @@ In the SIMD VSX set, section 6.8.1 and 6.8.2 p254 of v3.0B has a series of pack
 * See <https://bugs.libre-soc.org/show_bug.cgi?id=230#c30>
 * <https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-June/004911.html>
 
-Pack and unpack may be covered by [[remap]] by using Matrix 2D layouts on either source or destination but is quite expensive to do so.  Additionally,
+Pack and unpack may be covered by [[sv/remap]] by using Matrix 2D layouts on either source or destination but is quite expensive to do so.  Additionally,
 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
@@ -65,6 +65,10 @@ This results in a 3-element "pack"
 Both examples become particularly fun when Twin Predication is thrown
 into the mix.
 
+There exists room within the `svshape` instruction of  [[sv/remap]]
+to request some alternative Matrix mappings, and there is also
+room within the reserved bits of `svremap` as well.
+
 # RM Mode Concept:
 
 MVRM-2P-2S1D: