From 215d319fc961ca24a934079fc2fe20110da2e44b Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 13 Aug 2022 11:58:33 +0100 Subject: [PATCH] --- openpower/sv/ldst.mdwn | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/openpower/sv/ldst.mdwn b/openpower/sv/ldst.mdwn index 2bd8d3bd9..f5f45b694 100644 --- a/openpower/sv/ldst.mdwn +++ b/openpower/sv/ldst.mdwn @@ -66,6 +66,7 @@ an alternative table meaning for [[sv/svp64]] mode. The following modes make se * normal * fail-first (where Vector Indexed is banned) * Signed Effective Address computation (Vector Indexed only) +* Pack/Unpack (on LD/ST immediate operations only) More than that however it is necessary to fit the usual Vector ISA capabilities onto both Power ISA LD/ST with immediate and to @@ -88,7 +89,7 @@ The table for [[sv/svp64]] for `immed(RA)` is: | 0-1 | 2 | 3 4 | description | | --- | --- |---------|--------------------------- | | 00 | 0 | zz els | normal mode | -| 00 | 1 | rsvd | reserved | +| 00 | 1 | zz els | Structured Pack/Unpack | | 01 | inv | CR-bit | Rc=1: ffirst CR sel | | 01 | inv | els RC1 | Rc=0: ffirst z/nonz | | 10 | N | zz els | sat mode: N=0/1 u/s | @@ -321,6 +322,24 @@ Therefore, Fail-First LD/ST in Vertical-First is `UNDEFINED`. This is very different from Arithmetic (Data-dependent) FFirst where Vertical-First Mode is fully deterministic, not speculative. +# LD/ST Pack/Unpack Mode + +As described in [[sv/normal], +Structured Pack/Unpack is similar to VSX `vpack` and `vunpack` except +generalised not only to a Schedule to be applied to any operation but +also extended to vec2/3/4. + +Just as in [[sv/normal] operations, +setting this mode changes the meaning of bits 4-5 in `RM` from being +`ELWIDTH` to a pair of Pack/Unpack bits. Thus it is not possible +to separately override source and destination elwidths at the same +time as use Pack/Unpack: the `SRC_ELWIDTH` bits (6-7) must be used as +both source and destination elwidth. + +Pack/Unpack only applies to LD/ST-immediate operations. +See [[sv/svp64/appendix]] for details on how Pack/Unpack +is implemented. + # LOAD/STORE Elwidths Loads and Stores are almost unique in that the OpenPOWER Scalar ISA @@ -329,8 +348,8 @@ others like it provide an explicit operation width. There are therefore *three* widths involved: * operation width (lb=8, lh=16, lw=32, ld=64) -* src elelent width override -* destination element width override +* src elelent width override (8/16/32/default) +* destination element width override (8/16/32/default) Some care is therefore needed to express and make clear the transformations, which are expressly in this order: @@ -349,8 +368,10 @@ is treated effectively as completely separate and distinct from SV augmentation. This is primarily down to quirks surrounding LE/BE and byte-reversal in OpenPOWER. -It is unfortunately possible to request an elwidth override on the memory side which -does not mesh with the operation width: these result in `UNDEFINED` +It is rather unfortunately possible to request an elwidth override +on the memory side which +does not mesh with the overridden operation width: these result in +`UNDEFINED` behaviour. The reason is that the effect of attempting a 64-bit `sv.ld` operation with a source elwidth override of 8/16/32 would result in overlapping memory requests, particularly on unit and element strided -- 2.30.2