(no commit message)
authorlkcl <lkcl@web>
Fri, 27 May 2022 09:58:13 +0000 (10:58 +0100)
committerIkiWiki <ikiwiki.info>
Fri, 27 May 2022 09:58:13 +0000 (10:58 +0100)
openpower/sv/svp64_quirks.mdwn

index 134b361f8a584182d3feef38cc4fd5e350e27015..93f8a7775474191a4990cd943eb3b687835ac7ee 100644 (file)
@@ -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.