From ebd65045133ed17d14d1867622e5db984209d793 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 28 Mar 2023 00:45:30 +0100 Subject: [PATCH] --- openpower/sv/mv.vec.mdwn | 72 ++++++---------------------------------- 1 file changed, 10 insertions(+), 62 deletions(-) diff --git a/openpower/sv/mv.vec.mdwn b/openpower/sv/mv.vec.mdwn index fa84cdf26..9190fcdc7 100644 --- a/openpower/sv/mv.vec.mdwn +++ b/openpower/sv/mv.vec.mdwn @@ -3,75 +3,23 @@ # Vector Pack/Unpack operations In the SIMD VSX set, section 6.8.1 and 6.8.2 p254 of v3.0B has a series of pack and unpack operations. Additional pixel pack/unpack instructions -also exist. This page covers those and more. [[svp64]] provides the Vector Context to also add saturation as well as predication. +also exist. + +In SVP64, Pack and Unpack are achieved *in the abstract* for application on *all* +Vectoriseable instructions. * See * -Pack and unpack may be covered by [[sv/remap]] by using Matrix 2D layouts on either source or destination but is quite expensive to do so. Additionally, +The effect of Pack and unpack could be covered by [[sv/remap]] by using Matrix 2D layouts on either source or destination but is quite expensive to do so. Additionally, with pressure on the Scalar 32-bit opcode space it is more appropriate to -compromise by adding required capability in SVP64 on top of a -base pre-existing Scalar mv instruction. [[sv/mv.swizzle]] is sufficiently +compromise by adding required capability in SVP64 as a high priority +(part of the Management Instructions). [[sv/mv.swizzle]] is sufficiently unusual to justify a base Scalar 32-bit instruction but pack/unpack is not. -What, ultimately, was decided, was to make Pack/Unpack an `SVP64.RM` Mode. - -# REMAP concept for pack/unpack - -It may be possible to use one standard mv instruction to perform packing -and unpacking: Matrix allows for both reordering and offsets. At the very least a predicate mask potentially can -be used. - -* If a single src-dest mv is used, then it potentially requires - two separate REMAP and two separate sv.mvs: remap-even, sv.mv, - remap-odd, sv.mv -* If adding twin-src and twin-dest that is a lot of instructions, - particularly if triple is added as well. FPR mv, GPR mv -* Unless twin or triple is added, how is it possible to determine - the extra register(s) to be merged (or split)? - -How about instead relying on the implicit RS=MAXVL+RT trick and -extending that to RS=MAXVL+RA as a source? One spare bit in the -EXTRA RM area says whether the sv.mv is a pack (RS-as-src=RA+MAXVL) -or unpack (RS-as-dest=RT+MAXVL) - -Alternatively, given that Matrix is up to 3 Dimensions, not even -be concerned about RS, just simply use one of those dimensions to -span the packing: - -Example 1: - -* RA set to linear -* RT set to YX, ydim=2, xdim=4 -* VL=MAXVL=8 - -The indices match up as follows: - - | RA | (0 1) (2 3) (4 5) (6 7) | - | RT | 0 2 4 8 1 3 5 7 | - -This results in a 2-element "unpack" - -Example 2: - -* RT set to linear -* RT set to YX, ydim=3, xdim=3 -* VL=MAXVL=9 - -The indices match up as follows: - - | RA | 0 1 2 3 4 5 6 7 8 | - | RT | (0 3 6) (1 4 7) (2 5 8) | - -This results in a 3-element "pack" - -Both examples become particularly fun when Twin Predication is thrown -into the mix. - -There exists room within the `svshape` instruction of [[sv/remap]] -to request some alternative Matrix mappings, and there is also -room within the reserved bits of `svremap` as well. +What, ultimately, was decided, was to make Pack/Unpack part of the +`SVSTATE` [[sv/spr]]. -# RM Pack/unpack +# SVSTATE Pack/unpack Mode bits Described in [[svp64/appendix]] the Pack/Unpack Modes allow selective Transposition of Sub-vector elements, on both source and destination. -- 2.30.2