From: lkcl <lkcl@web>
Date: Fri, 27 May 2022 09:58:13 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~2066
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=5e0717b68f7ae2801829f3c27da43ab127ddeff9;p=libreriscv.git

---

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 134b361f8..93f8a7775 100644
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -37,3 +37,28 @@ such as they are, are still packed sequentially.
 From a hardware implementation perspective however they will need special
 handling as far as Hazard Dependencies are concerned, due to nonconformance
 (bit-level management)
+
+# mv.x
+
+[[sv/mv.x]] aka `GPR(RT) = GPR(GPR(RA))` is so horrendous in
+terms of Register Hazard Management that its addition to any Scalar
+ISA is anathematic. In a Traditional Vector ISA however, where the
+indices are isolated behind a single Vector Hazard, there is no
+problem at all.  `sv.mv.x` is also fraught, precisely because it
+sits on top of a Standard Scalar register paradigm, not a Vector
+ISA, with separate and distinct Vector registers.
+
+To help partly solve this, `sv.mv.x` has to be made relative:
+
+```
+for i in range(VL):
+    GPR(RT+i) = GPR(RT+MIN(GPR(RA+i), VL))
+```
+
+The reason for doing so is that MAXVL or VL may be used to limit
+the number of Register Hazards that need to be raised to a fixed
+quantity, at Issue time.
+
+`mv.x` itself will still have to be added as a Scalar instruction,
+but the behaviour of `sv.mv.x` will have to be different from that
+Scalar version.