From: lkcl <lkcl@web>
Date: Sat, 13 Aug 2022 10:58:33 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~869
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=215d319fc961ca24a934079fc2fe20110da2e44b;p=libreriscv.git

---

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 <a name="elwidth"></a>
 
 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