(no commit message)
authorlkcl <lkcl@web>
Thu, 9 Jun 2022 13:00:35 +0000 (14:00 +0100)
committerIkiWiki <ikiwiki.info>
Thu, 9 Jun 2022 13:00:35 +0000 (14:00 +0100)
openpower/sv/svp64_quirks.mdwn

index e46e3feb33a1a3f03bcaa64775e91ba03a9422bf..93da4d218a7b5a8e34caa3521090cddc3ae21f2d 100644 (file)
@@ -271,7 +271,7 @@ 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
+# mv.x (vector permute)
 
 [[sv/mv.x]] aka `GPR(RT) = GPR(GPR(RA))` is so horrendous in
 terms of Register Hazard Management that its addition to any Scalar
@@ -281,7 +281,8 @@ 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:
+To help partly solve this, `sv.mv.x` would have had to have
+been made relative:
 
 ```
 for i in range(VL):
@@ -292,14 +293,15 @@ 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
+`mv.x` itself would still have to be added as a Scalar instruction,
+but the behaviour of `sv.mv.x` would have to be different from that
 Scalar version.
 
 Normally, Scalar Instructions have a good justification for being
 added as Scalar instructions on their own merit. `mv.x` is the
-polar opposite, and as such qualifies for a special mention in
-this section.
+polar opposite, and in the end, the idea was thrown out, and Indexed
+REMAP added in its place.  Indexed REMAP comes with its own quirks,
+solving the Hazard problem, described in a later section.
 
 # Branch-Conditional