[[!tag standards]]
-# SVP64 for OpenPOWER ISA v3.0B
+# DRAFT SVP64 for OpenPOWER ISA v3.0B
-**DRAFT STATUS**
+* **DRAFT STATUS v0.1 18sep2021** Release notes <https://bugs.libre-soc.org/show_bug.cgi?id=699>
This document describes [[SV|sv]] augmentation of the [[OpenPOWER|openpower]] v3.0B [[ISA|openpower/isa/]]. Permission to create commercial v3.1 implementations has not yet been granted through the issuance of a v3.1 EULA by the [[!wikipedia OpenPOWER_Foundation]] (only v3.0B)
+Credits and acknowledgements:
+
+* Luke Leighton
+* Jacob Lifshay
+* Hendrik Boom
+* Richard Wilbur
+* Alexandre Oliva
+* Cesar Strauss
+* NLnet Foundation, for funding
+* OpenPOWER Foundation
+* Paul Mackerras
+* Toshaan Bharvani
+* IBM for the Power ISA itself
+
Links:
* <http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001498.html>>
* Independent per-register Scalar/Vector tagging and range extension on every register
* Element width overrides on both source and destination
* Predication on both source and destination
-* Two different *types* of predication: INT and CR
-* SV Modes including saturation (for A/V DSP), mapreduce, fail-first and
+* Two different sources of predication: INT and CR Fields
+* SV Modes including saturation (for Audio, Video and DSP), mapreduce, fail-first and
predicate-result mode.
This document focusses specifically on how that fits into available space. The [[svp64/appendix]] explains more of the details, whilst the [[sv/overview]] gives the basics.
fields set to a reserved value must cause an illegal instruction trap,
to allow emulation of future instruction sets. Unless otherwise stated, reserved values are always all zeros.
-This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero.
+This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero. Where the standard OpenPOWER definition
+is intended the red keyword `RESERVED` is used.
# Identity Behaviour
| EXT01 | RM | 1 | RM | 1 | RM |
| 000001 | RM[0] | 1 | RM[1] | 1 | RM[2:23] |
-Following the prefix will be the suffix: this is simply a 32-bit v3.0B / v3.1B
+Following the prefix will be the suffix: this is simply a 32-bit v3.0B / v3.1
instruction. That instruction becomes "prefixed" with the SVP context: the
Remapped Encoding field (RM).
+It is important to note that unlike v3.1 64-bit prefixed instructions
+there is insufficient space in `RM` to provide identification of
+any SVP64 Fields without first partially decoding the
+32-bit suffix. Extreme caution and care must therefore be taken
+when extending SVP64 in future, to not create unnecessary relationships
+between prefix and suffix that could complicate decoding, adding latency.
+
# Common RM fields
The following fields are common to all Remapped Encodings:
| Field Name | Field bits | Description |
|------------|------------|----------------------------------------|
-| MASKMODE | `0` | Execution (predication) Mask Kind |
-| MASK | `1:3` | Execution Mask |
+| MASKMODE | `0` | Execution (predication) Mask Kind |
+| MASK | `1:3` | Execution Mask |
+| SUBVL | `8:9` | Sub-vector length |
+
+The following fields are optional or encoded differently depending
+on context after decoding of the Scalar suffix:
+
+| Field Name | Field bits | Description |
+|------------|------------|----------------------------------------|
| ELWIDTH | `4:5` | Element Width |
| ELWIDTH_SRC | `6:7` | Element Width for Source |
-| SUBVL | `8:9` | Sub-vector length |
+| EXTRA | `10:18` | Register Extra encoding |
| MODE | `19:23` | changes Vector behaviour |
+
* MODE changes the behaviour of the SV operation (result saturation, mapreduce)
* SUBVL groups elements together into vec2, vec3, vec4 for use in 3D and Audio/Video DSP work
* ELWIDTH and ELWIDTH_SRC overrides the instruction's destination and source operand width
* MASK (and MASK_SRC) and MASKMODE provide predication (two types of sources: scalar INT and Vector CR).
+* Bits 10 to 18 (EXTRA) are further decoded depending on the RM category for the instruction, which is determined only by decoding the Scalar 32 bit suffix.
-Bits 10 to 18 are further decoded depending on RM category for the instruction.
Similar to OpenPOWER `X-Form` etc. these are given designations, such as `RM-1P-3S1D` which indicates for this example that the operation is to be single-predicated and that there are 3 source operand EXTRA tags and one destination operand tag.
Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing.
# Mode
Mode is an augmentation of SV behaviour. Different types of
-instructions have different needs, similar to Power ISA 64 bit prefix
-8LS and MTRR formats.
+instructions have different needs, similar to Power ISA
+v3.1 64 bit prefix 8LS and MTRR formats apply to different
+instruction types. Modes include Reduction, Iteration, arithmetic
+saturation, and Fail-First. More specific details in each
+section and in the [[svp64/appendix]]
* For condition register operations see [[sv/cr_ops]]
* For LD/ST Modes, see [[sv/ldst]].
[`bf16`](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
is reserved for a future implementation of SV
-Note that any operation in Power ISA ending in "s" (`fadds`) shall
-perform its operation at **half** the ELWIDTH. `sv.fadds/ew=f32` shall perform an IEEE754 FP16 operation that is then "padded" to fill out to an IEEE754 FP32.
+Note that any IEEE754 FP operation in Power ISA ending in "s" (`fadds`) shall
+perform its operation at **half** the ELWIDTH then padded back out
+to ELWIDTH. `sv.fadds/ew=f32` shall perform an IEEE754 FP16 operation that is then "padded" to fill out to an IEEE754 FP32. When ELWIDTH=DEFAULT
+clearly the behaviour of `sv.fadds` is performed at 32-bit accuracy
+then padded back out to fit in IEEE754 FP64, exactly as for Scalar
+v3.0B "single" FP.
## Elwidth for CRs:
-TODO, important, particularly for crops, mfcr and mtcr, what elwidth
-even means. instead it may be possible to use the bits as extra indices
-(add to EXTRA2/3) to access the full 128 CRs at the bit level. TBD, several ideas
-
-The actual width of the CRs cannot be altered: they are 4 bit. Also,
-for Rc=1 operations that produce a result (in RT or FRT) and corresponding CR, it is
-the INT/FP result to which the elwidth override applies, *not* the CR.
-This therefore inherently places Rc=1 operations firmly out of scope as far as a "meaning" for elwidth on CRs is concerned.
-
-As mentioned TBD, this leaves crops etc. to have a meaning defined for
-elwidth, because these ops are pure explicit CR based.
+Element-width overrides for CR Fields has no meaning. The bits
+are therefore used for other purposes, or when Rc=1, the Elwidth
+applies to the result being tested, but not to the Vector of CR Fields.
-Examples: mfxm may take the extra bits and use them as extra mask bits.
-
-Example: hypothetically, operations could be modified to be considered 2-bit or 1-bit per CR. This would need a very comprehensive review.
# SUBVL Encoding
Shows all instruction-specific fields in the Remapped Encoding `RM[10:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to OpenPOWER "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*).
+These mappings are part of the SVP64 Specification in exactly the same
+way as X-Form, D-Form. New Scalar instructions added to the Power ISA
+will need a corresponding SVP64 Mapping, which can be derived by-rote
+from examining the Register "Profile" of the instruction.
+
There are two categories: Single and Twin Predication.
Due to space considerations further subdivision of Single Predication
-is based on whether the number of src operands is 2 or 3.
+is based on whether the number of src operands is 2 or 3. With only
+9 bits available some compromises have to be made.
* `RM-1P-3S1D` Single Predication dest/src1/2/3, applies to 4-operand instructions (fmadd, isel, madd).
* `RM-1P-2S1D` Single Predication dest/src1/2 applies to 3-operand instructions (src1 src2 dest)
`RM-2P-2S` is for `stw` etc. and is Rsrc1 Rsrc2.
+## RM-1P-2S1D
+
+single-predicate, three registers (2 read, 1 write)
+
+| Field Name | Field bits | Description |
+|------------|------------|----------------------------|
+| Rdest_EXTRA3 | `10:12` | extends Rdest |
+| Rsrc1_EXTRA3 | `13:15` | extends Rsrc1 |
+| Rsrc2_EXTRA3 | `16:18` | extends Rsrc2 |
+
## RM-2P-2S1D/1S2D/3S
The primary purpose for this encoding is for Twin Predication on LOAD
projects / libreriscv.git / blobdiff