# Condition Register SVP64 Operations
+**DRAFT STATUS**
+
Links:
* <https://bugs.libre-soc.org/show_bug.cgi?id=687>
+* <https://bugs.libre-soc.org/show_bug.cgi?id=936> write on failfirst
* [[svp64]]
* [[sv/branches]]
+* [[sv/cr_int_predication]]
* [[openpower/isa/sprset]]
* [[openpower/isa/condition]]
* [[openpower/isa/comparefixed]]
Condition Register Fields are only 4 bits wide: this presents some
-interesting conceptual challenges for SVP64, particularly with respect to element
-width (which is clearly meaningless for a 4-bit
-collation of Conditions, EQ LT GE SO). Likewise, arithmetic saturation
-(an important part of Arithmetic SVP64)
-has no meaning. Additionally, extra modes are required that only make
-sense for Vectorised CR Operations. Consequently an alternative Mode Format is required.
+interesting conceptual challenges for SVP64, which was designed
+primarily for vectors of arithmetic and logical operations. However
+if predicates may be bits of CR Fields it makes sense to extend
+Simple-V to cover CR Operations, especially given that Vectorised Rc=1
+may be processed by Vectorised CR Operations that usefully in turn
+may become Predicate Masks to yet more Vector operations, like so:
+
+```
+ sv.cmpi/ew=8 *B,*ra,0 # compare bytes against zero
+ sv.cmpi/ew=8 *B2,*ra,13. # and against newline
+ sv.cror PM.EQ,B.EQ,B2.EQ # OR compares to create mask
+ sv.stb/sm=EQ ... # store only nonzero/newline
+```
+
+Element width however is clearly meaningless for a 4-bit collation of
+Conditions, EQ LT GE SO. Likewise, arithmetic saturation (an important
+part of Arithmetic SVP64) has no meaning. An alternative Mode Format is
+required, and given that elwidths are meaningless for CR Fields the bits
+in SVP64 `RM` may be used for other purposes.
This alternative mapping **only** applies to instructions that **only**
reference a CR Field or CR bit as the sole exclusive result. This section
**does not** apply to instructions which primarily produce arithmetic
-results that also, as an aside, produce a corresponding
-CR Field (such as when Rc=1).
-Instructions that involve Rc=1 are definitively arithmetic in nature,
-where the corresponding Condition Register Field can be considered to
-be a "co-result". Such CR Field "co-result" arithmeric operations
-are firmly out of scope for
-this section.
+results that also, as an aside, produce a corresponding CR Field (such as
+when Rc=1). Instructions that involve Rc=1 are definitively arithmetic
+in nature, where the corresponding Condition Register Field can be
+considered to be a "co-result". Such CR Field "co-result" arithmeric
+operations are firmly out of scope for this section, being covered fully
+by [[sv/normal]].
* Examples of v3.0B instructions to which this section does
- apply is `mfcr` (3 bit operands) and `crnor` (5 bit operands).
+ apply is
+ - `mfcr` and `cmpi` (3 bit operands) and
+ - `crnor` and `crand` (5 bit operands).
* Examples to which this section does **not** apply include
`fadds.` and `subf.` which both produce arithmetic results
(and a CR Field co-result).
+* `mtcr` is considered [[openpower/sv/normal]] because it refers
+ to the entire 32-bit Condition Register rather than to CR Fields.
+
+The CR Mode Format still applies to `sv.cmpi` because despite
+taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
+instruction is purely to a Condition Register Field.
Other modes are still applicable and include:
* **Data-dependent fail-first**.
- useful to truncate VL based on
- analysis of a Condition Register result bit.
-* **Scalar and parallel reduction**.
- Reduction is useful
-for analysing a Vector of Condition Register Fields
-and reducing it to one
-single Condition Register Field.
-* **Predicate-result**.
- Equivalent
-to python "filter", in that only elements which pass a test
-will end up actually being modified. This is in effect the same
-as ANDing the Condition Test with the destination predicate
-mask (hence the name, "predicate-result").
-
-Predicate-result is a particularly powerful strategic mode
-in that it is the interaction of a source predicate, destination predicate,
-input operands *and* the output result, all combining to influence
-what actually goes into the Condition Register File. Given that
-predicates may themselves be Condition Registers it can be seen that
-there could potentially be up to **six** CR Fields involved in
-the execution of Predicate-result Mode.
-
-SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations:
-
-| 4 | 5 | 19-20 | 21 | 22 23 | description |
-| - | - | ----- | --- |---------|----------------- |
-|sz |SNZ| 00 | 0 | dz / | 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 |
-|dz |SNZ| 01/10 | inv | CR-bit | Ffirst 3-bit mode |
-|sz |SNZ| 01/10 | inv | dz / | Ffirst 5-bit mode |
-|sz |SNZ| 11 | inv | CR-bit | 3-bit pred-result CR sel |
-|sz |SNZ| 11 | inv | dz / | 5-bit pred-result z/nonz |
-
-`VLI=0` when bits 19-20=0b01.
-`VLI=1` when bits 19-20=0b10.
+ useful to truncate VL based on analysis of a Condition Register result bit.
+* **Reduction**.
+ Reduction is useful for analysing a Vector of Condition Register Fields
+ and reducing it to one single Condition Register Field.
+
+Predicate-result does not make any sense because when Rc=1 a co-result
+is created (a CR Field). Testing the co-result allows the decision to
+be made to store or not store the main result, and for CR Ops the CR
+Field result *is* the main result.
+
+## Format
+
+SVP64 RM `MODE` (includes `ELWIDTH_SRC` bits) for CR-based operations:
+
+|6 | 7 |19:20|21 | 22:23 | description |
+|--|---|-----|---|---------|------------------|
+|/ | / |RG 0 | 0 | dz sz | simple mode |
+|/ | / |RG 0 | 1 | dz sz | scalar reduce mode (mapreduce) |
+|zz|SNZ|VLI 1|inv| CR-bit | Ffirst 3-bit mode |
+|/ |SNZ|VLI 1|inv| dz sz | Ffirst 5-bit mode (implies CR-bit from result) |
Fields:
-TODO
+* **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.
+* **zz** set both sz and dz equal to this flag
+* **SNZ** In fail-first mode, on the bit being tested, when sz=1 and
+ SNZ=1 a value "1" is put in place of "0".
+* **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** Reverse-Gear: inverts the Vector Loop order (VL-1 downto 0) rather
+ than the normal 0 upto VL-1
+* **SVM** sets "subvector" reduce mode
+* **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.
-# Data-dependent fail-first on CR operations
+## Data-dependent fail-first on CR operations
-The principle of data-dependent fail-first is that if a Condition Test
-fails then VL (Vector Length) is truncated at that point. In the case
-of Arithmetic SVP64 Operations the Condition Register Field generated from
-Rc=1 is used, however with CR-based operations that CR result is provided
-by the operation itself.
+The principle of data-dependent fail-first is that if, during the course
+of sequentially evaluating an element's Condition Test, one such test
+is encountered which fails, then VL (Vector Length) is truncated (set)
+at that point. In the case of Arithmetic SVP64 Operations the Condition
+Register Field generated from Rc=1 is used as the basis for the truncation
+decision. However with CR-based operations that CR Field result to be
+tested is provided *by the operation itself*.
-Data-dependent SVP64 Vectorised Operations involving the creation or
-modification of a CR can require an extra two bits, which are not available
-in the compact space of the SVP64 RM `MODE` Field. With the concept of element
-width overrides being meaningless for CR Fields it is possible to use the
-`ELWIDTH` field for alternative purposes.
+Data-dependent SVP64 Vectorised Operations involving the creation
+or modification of a CR can require an extra two bits, which are not
+available in the compact space of the SVP64 RM `MODE` Field. With the
+concept of element width overrides being meaningless for CR Fields it
+is possible to use the `ELWIDTH` field for alternative purposes.
-Condition Register based operations such as `sv.mfcr` and `sv.crand` can thus
-be made more flexible. However the rules that apply in this section
-also apply to future CR-based instructions.
+Condition Register based operations such as `sv.mfcr` and `sv.crand`
+can thus be made more flexible. However the rules that apply in this
+section also apply to future CR-based instructions.
There are two primary different types of CR operations:
* Those which have a 5-bit operand (referring to a bit within the
whole 32-bit CR)
-Examining these two types it is observed that the
-difference may be considered to be that the 5-bit variant provides
-additional information about which CR Field bit (EQ, GE, LT, SO) is to
-be operated on by the instruction.
-Thus, logically, we may set the following rule:
+Examining these two types it is observed that the difference may
+be considered to be that the 5-bit variant *already* provides the
+prerequisite information about which CR Field bit (EQ, GE, LT, SO) is
+to be operated on by the instruction. Thus, logically, we may set the
+following rule:
* When a 5-bit CR Result field is used in an instruction, the
5-bit variant of Data-Dependent Fail-First
must be used. i.e. the bit of the CR field to be tested is
the one that has just been modified (created) by the operation.
* When a 3-bit CR Result field is used the 3-bit variant
- must be used, providing as it does the missing `CRbit`
+ must be used, providing as it does the missing `CRbit` field
in order to select which CR Field bit of the result shall
be tested (EQ, LE, GE, SO)
-The reason why the 3-bit CR variant needs the additional CR-bit
-field should be obvious from the fact that the 3-bit CR Field
-from the base Power ISA v3.0B operation clearly does not contain
-and is missing the two CR Field Selector bits. Thus, these two
-bits (to select EQ, LE, GE or SO) must be provided in another
-way.
+The reason why the 3-bit CR variant needs the additional CR-bit field
+should be obvious from the fact that the 3-bit CR Field from the base
+Power ISA v3.0B operation clearly does not contain and is missing the
+two CR Field Selector bits. Thus, these two bits (to select EQ, LE,
+GE or SO) must be provided in another way.
Examples of the former type:
VL to include the element being tested (`VLi=1`) and to exclude it
(`VLi=0`).
-# Predicate-result Condition Register operations
-
-These are again slightly different compared to SVP64 arithmetic
-pred-result (described in [[svp64/appendix]]). The reason is that,
-again, for arithmetic operations the production of a CR Field when
-Rc=1 is a *co-result* accompanying the main arithmetic result, whereas
-for CR-based operations the CR Field (referred to by a 3-bit
-v3.0B base operand from e.g. `mfcr`) or CR bit (referred to by a 5-bit operand from e.g. `crnor`)
-*is* itself the explicit and sole result of the operation.
-
-Therefore, logically, Predicate-result needs to be adapted to
-test the actual result of the CR-based instruction (rather than
-test the co-resultant CR when Rc=1, as is done for Arithmetic SVP64).
-
- for i in range(VL):
- # predication test, skip all masked out elements.
- # skips when sz=0
- if sz=0 and predicate_masked_out(i):
- continue
- if predicate_masked_out(i):
- if 5bit mode:
- # only one bit of CR to update
- result = SNZ
- else
- # four copies of SNZ
- result = SNZ || SNZ || SNZ || SNZ
- else
- # result is to go into CR. may be a 4-bit CR Field
- # (3-bit mode) or just a single bit (5-bit mode)
- result = op(...)
- if 5bit mode:
- # if this CR op has 5-bit CR result operands
- # the single bit result is what must be tested
- to_test = result
- else
- # if however this is a 3-bit CR *field* result
- # then the bit to be tested must be selected
- to_test = result[CRbit]
- # now test CR, similar to branch
- if to_test != inv:
- continue # test failed: cancel store
- # result optionally stored
- update_CR(result)
+Also exactly as with [[sv/normal]] fail-first, VL cannot, unlike
+[[sv/ldst]], be set to an arbitrary value. Deterministic behaviour
+is *required*.
+
+## Reduction and Iteration
+
+Bearing in mind as described in the [[svp64/appendix]] SVP64 Horizontal
+Reduction is a deterministic schedule on top of base Scalar v3.0
+operations, the same rules apply to CR Operations, i.e. that programmers
+must follow certain conventions in order for an *end result* of a
+reduction to be achieved. Unlike other Vector ISAs *there are no explicit
+reduction opcodes* in SVP64: Schedules however achieve the same effect.
+
+Due to these conventions only reduction on operations such as `crand`
+and `cror` are meaningful because these have Condition Register Fields
+as both input and output. Meaningless operations are not prohibited
+because the cost in hardware of doing so is prohibitive, but neither
+are they `UNDEFINED`. Implementations are still required to execute them
+but are at liberty to optimise out any operations that would ultimately
+be overwritten, as long as Strict Program Order is still obvservable by
+the programmer.
+
+Also bear in mind that 'Reverse Gear' may be enabled, which can be
+used in combination with overlapping CR operations to iteratively
+accumulate results. Issuing a `sv.crand` operation for example with
+`BA` differing from `BB` by one Condition Register Field would result
+in a cascade effect, where the first-encountered CR Field would set the
+result to zero, and also all subsequent CR Field elements thereafter:
+
+```
+ # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
+ for i in VL-1 downto 0 # reverse gear
+ CR.field[4+i].ge &= CR.field[5+i].ge
+```
+
+`sv.crxor` with reduction would be particularly useful for parity
+calculation for example, although there are many ways in which the same
+calculation could be carried out (`parityw`)
+after transferring a vector of CR Fields
+to a GPR using crweird operations.
+
+Implementations are free and clear to optimise these reductions in any way
+they see fit, as long as the end-result is compatible with Strict Program
+Order being observed, and Interrupt latency is not adversely impacted.
+Good examples include `sv.cror/mr` which is a cumulative ORing of
+a Vector of CR Field bits, and consequently an easy target for
+parallelising.
+
+## Unusual and quirky CR operations
+
+**cmp and other compare ops**
+
+`cmp` and `cmpi` etc take GPRs as sources and create a CR Field as a result.
+
+```
+ cmpli BF,L,RA,UI
+ cmpeqb BF,RA,RB
+```
+
+With `ELWIDTH` applying to the source GPR operands this is perfectly fine.
+
+**crweird operations**
+
+There are 4 weird CR-GPR operations and one reasonable one in
+the [[cr_int_predication]] set:
+
+* crrweird
+* mtcrweird
+* crweirder
+* crweird
+* mcrfm - reasonably normal and referring to CR Fields for src and dest.
+
+The "weird" operations have a non-standard behaviour, being able to
+treat *individual bits* of a GPR effectively as elements. They are
+expected to be Micro-coded by most Hardware implementations.
+
+## Effectively-separate Vector and Scalar Condition Register file
+
+As mentioned in the introduction on [[sv/svp64]] some prohibitions
+are made on instructions involving Condition Registers that allow
+implementors to actually consider the Scalar CR (fields CR0-CR7)
+as a completely separate register file from the Vector CRs
+(fields CR8-CR127).
+
+The complications arise for existing Hardware implementations
+due to Power ISA not having had "Conditional Execution" added.
+Adding entirely new pipelines and a new Vector CR Register file
+is a much easier proposition to consider.
+
+The prohibitions utilise the CR Field numbers implicitly to
+split out Vectorised CR operations to be considered completely
+separare and distinct from Scalar CR operations *even though
+they both use the same binary encoding*. This does in turn
+mean that at the Decode Phase it becomes necessary to examine
+not only the operation (`sv.crand`, `sv.cmp`) but also
+the CR Field numbers as well as whether, in the EXTRA2/3 Mode
+bits, the operands are Vectorised.
+
+A future version of Power ISA, where SVP64Single is proposed,
+would in fact introduce "Conditional Execution", including
+for VSX. At which point this prohibition becomes moot as
+Predication would be required to be added into the existing
+Scalar (and PackedSIMD VSX) side of existing Power ISA
+implementations.
+
+
+--------
+
+[[!tag standards]]
+
+\newpage{}
+
projects / libreriscv.git / blobdiff