**DRAFT STATUS**
-This document describes [[SV|sv]] augmentation of the [[OpenPOWER|openpower]] v3.0B [[ISA|openpower/isa/]]. Permission to create commercial v3.1B implementations has not yet been granted through the issuance of a v3.1B EULA by the [[!wikipedia OpenPOWER_Foundation]] (only v3.0B)
+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)
Links:
| 0:5 | 6:31 | 0:31 |
|--------|--------------|--------------|
-| EXT01 | v3.1B Prefix | v3.1B Suffix |
+| EXT01 | v3.1 Prefix | v3.1 Suffix |
-svp64 fits into the "reserved" portions of the v3.1B prefix, making it possible for svp64, v3.0B (or v3.1B including 64 bit prefixed) instructions to co-exist in the same binary without conflict.
+svp64 fits into the "reserved" portions of the v3.1 prefix, making it possible for svp64, v3.0B (or v3.1 including 64 bit prefixed) instructions to co-exist in the same binary without conflict.
## SVP64 encoding features
Mode is an augmentation of SV behaviour. Some of these alterations are element-based (saturation), others involve post-analysis (predicate result) and others are Vector-based (mapreduce, fail-on-first).
-These are the modes:
+These are the modes for everything except [[sv/ldst]] and [[sv/branches]]:
* **normal** mode is straight vectorisation. no augmentations: the vector comprises an array of independently created results.
* **ffirst** or data-dependent fail-on-first: see separate section. the vector may be truncated depending on certain criteria.
*VL is altered as a result*.
-* **sat mode** or saturation: clamps each elemrnt result to a min/max rather than overflows / wraps. allows signed and unsigned clamping.
+* **sat mode** or saturation: clamps each element result to a min/max rather than overflows / wraps. allows signed and unsigned clamping for both INT
+and FP.
* **reduce mode**. a mapreduce is performed. the result is a scalar. a result vector however is required, as the upper elements may be used to store intermediary computations. the result of the mapreduce is in the first element with a nonzero predicate bit. see [[appendix]]
note that there are comprehensive caveats when using this mode.
-* **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch testing) and if the test fails it is as if the predicate bit was zero. When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed. This scheme does not apply to crops (crand, cror). See appendix for details.
+* **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch testing) and if the test fails it is as if the
+*destination* predicate bit was zero. When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed. This scheme does not apply to crops (crand, cror). See appendix for details.
Note that ffirst and reduce modes are not anticipated to be high-performance in some implementations. ffirst due to interactions with VL, and reduce due to it requiring additional operations to produce a result. normal, saturate and pred-result are however inter-element independent and may easily be parallelised to give high performance, regardless of the value of VL.
-The Mode table for operations except LD/ST is laid out as follows:
+The Mode table for operations except LD/ST and Branch Conditional
+ is laid out as follows:
| 0-1 | 2 | 3 4 | description |
| --- | --- |---------|-------------------------- |
-| 00 | 0 | sz dz | normal mode |
-| 00 | 1 | sz CRM | reduce mode (mapreduce), SUBVL=1 |
-| 00 | 1 | SVM CRM | subvector reduce mode, SUBVL>1 |
+| 00 | 0 | dz sz | normal mode |
+| 00 | 1 | 0 RG | scalar reduce mode (mapreduce), SUBVL=1 |
+| 00 | 1 | 1 CRM | parallel reduce mode (mapreduce), SUBVL=1 |
+| 00 | 1 | SVM RG | subvector reduce mode, SUBVL>1 |
| 01 | inv | CR-bit | Rc=1: ffirst CR sel |
-| 01 | inv | sz RC1 | Rc=0: ffirst z/nonz |
-| 10 | N | sz dz | sat mode: N=0/1 u/s |
+| 01 | inv | VLi RC1 | Rc=0: ffirst z/nonz |
+| 10 | N | dz sz | sat mode: N=0/1 u/s |
| 11 | inv | CR-bit | Rc=1: pred-result CR sel |
-| 11 | inv | sz RC1 | Rc=0: pred-result z/nonz |
+| 11 | inv | dz RC1 | Rc=0: pred-result z/nonz |
Fields:
* **sz / dz** if predication is enabled will put zeros into the dest (or as src in the case of twin pred) when the predicate bit is zero. otherwise the element is ignored or skipped, depending on context.
* **inv CR bit** just as in branches (BO) these bits allow testing of a CR bit and whether it is set (inv=0) or unset (inv=1)
+* **RG** inverts the Vector Loop order (VL-1 downto 0) rather
+than the normal 0..VL-1
* **CRM** affects the CR on reduce mode when Rc=1
* **SVM** sets "subvector" reduce mode
* **N** sets signed/unsigned saturation.
-**RC1** as if Rc=1, stores CRs *but not the result*
+* **RC1** as if Rc=1, stores CRs *but not the result*
+* **VLi** VL inclusive: in fail-first mode, the truncation of
+ VL *includes* the current element at the failure point rather
+ than excludes it from the count.
-## LD/ST ffirst
-
-ffirst LD/ST to multiple pages via a Vectorised base is considered a security risk due to the abuse of probing multiple pages in rapid succession and getting feedback on which pages would fail. Therefore in these special circumstances requesting ffirst with a vector base is instead interpreted as element-strided LD/ST. See <https://bugs.libre-soc.org/show_bug.cgi?id=561>
-and [[sv/ldst]]
+For LD/ST Modes, see [[sv/ldst]]. For Branch modes, see [[sv/branches]] Immediate and Indexed LD/ST
+are both different, in order to support a large range of features
+normally found in Vector ISAs.
# ELWIDTH Encoding
Likewise CR based twin predication has a second set of 3 bits, allowing
a different test to be applied.
+Note that it is assumed that Predicate Masks (whether INT or CR)
+are read *before* the operations proceed. In practice (for CR Fields)
+this creates an unnecessary block on parallelism. Therefore,
+it is up to the programmer to ensure that the CR fields used as
+Predicate Masks are not being written to by any parallel Vector Loop.
+Doing so results in **UNDEFINED** behaviour, according to the definition
+outlined in the OpenPOWER v3.0B Specification.
+
+Hardware Implementations are therefore free and clear to delay reading
+of individual CR fields until the actual predicated element operation
+needs to take place, safe in the knowledge that no programmer will
+have issued a Vector Instruction where previous elements could have
+overwritten (destroyed) not-yet-executed CR-Predicated element operations.
+
## Integer Predication (MASKMODE=0)
When the predicate mode bit is zero the 3 bits are interpreted as below.
projects / libreriscv.git / blobdiff