From 7399de0ca8f2690061609cc74158c16e37373972 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 17 Aug 2022 14:48:56 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index b8a862bab..2b1a57aa9 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -578,15 +578,20 @@ comes when Pack/Unpack are enabled, and it is really important to be aware how the Arrays of vec2/3/4 become re-ordered *and swizzled at the same time*. -Pack/Unpack applies to -[[sv/mv.vec]] as well however the uniform relationship and -the fact that the source and destination subvector length -must be the same (vec2/3/4) makes things slightly easier to -understand. The main thing to keep in mind about Pack/Unpack +Pack/Unpack started out as +[[sv/mv.vec]] but became its own distinct Mode over time. +The main thing to keep in mind about Pack/Unpack is that it engages a swap of the ordering of the VL-SUBVL nested for-loops, in exactly the same way that Matrix REMAP -can do. When Pack or Unpack is enabled it is the SUBVL for-loop -that becomes outermost. +can do. +When Pack or Unpack is enabled it is the SUBVL for-loop +that becomes outermost. A bit of thought shows that this is +a 2D "Transpose" where Dimension X is VL and Dimension Y is SUBVL. +However *both* source *and* destination may be independently +"Transposed", which makes no sense at all until the fact that +Swizzle can have a *different SUBVL* is taken into account. + +Basically Pack/Unpack # No Scalar GPR Move -- 2.30.2