From 5e0717b68f7ae2801829f3c27da43ab127ddeff9 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 27 May 2022 10:58:13 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) 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. -- 2.30.2