(no commit message)
[libreriscv.git] / openpower / sv / cr_ops.mdwn
1 # Condition Register SVP64 Operations
2
3 Condition Register Fields are only 4 bits wide: this presents some
4 interesting conceptual challenges for SVP64, particularly with respect to element
5 width (which is clearly meaningless). Likewise, arithmetic saturation
6 (an important part of Arithmetic SVP64)
7 has no meaning. Consequently an alternative Mode Format is required.
8
9 This alternative mapping **only** applies to instructions that **only**
10 reference a CR Field or CR bit as the sole exclusive result. This section
11 **does not** apply to instructions which primarily produce arithmetic
12 results that also, as an aside, produce a corresponding
13 CR Field (such as when Rc=1).
14 Instructions that involve Rc=1 are definitively arithmetic in nature,
15 where the corresponding Condition Register Field can be considered to
16 be a "co-result". Thus, if the arithmetic result is Vectorised, so
17 is the CR Field "co-result", which puts both firmly out of scope for
18 this section.
19
20 Other modes are still applicable and include:
21
22 * **Data-dependent fail-first**.
23 useful to truncate VL based on
24 analysis of a Condition Register result bit.
25 * **Scalar and parallel reduction**.
26 Reduction is useful
27 for turning a Vector of Condition Register Fields into one
28 single Condition Register.
29 * **Predicate-result**.
30 Equivalent
31 to python "filter", in that only elements which pass a test
32 will end up actually being modified. This is in effect the same
33 as ANDing the Condition Test with the destination predicate
34 mask (hence the name, "predicate-result").
35
36 SVP64 RM `MODE` (includes `ELWIDTH` bits) for CR-based operations:
37
38 | 4 | 5 | 19-20 | 21 | 22 23 | description |
39 | - | - | ----- | --- |---------|----------------- |
40 |dz |VLi| 01 | inv | CR-bit | Ffirst 3-bit mode |
41 |sz |VLi| 01 | inv | dz Rc1 | Ffirst 5-bit mode |
42 | / | / | 00 | 0 | dz sz | normal mode |
43 | / | / | 00 | 1 | 0 RG | scalar reduce mode (mapreduce), SUBVL=1 |
44 | / | / | 00 | 1 | 1 CRM | parallel reduce mode (mapreduce), SUBVL=1 |
45 | / | / | 00 | 1 | SVM RG | subvector reduce mode, SUBVL>1 |
46 | / | / | 10 | / | / / | RESERVED |
47 |dz | / | 11 | inv | CR-bit | 3-bit pred-result CR sel |
48 | / | / | 11 | inv | dz sz | 5-bit pred-result z/nonz |
49
50 Fields:
51
52 TODO
53
54 # Data-dependent fail-first on CR operations
55
56 Data-dependent SVP64 Vectorised Operations involving the creation or
57 modification of a CR require an extra two bits, which are not available
58 in the compact space of the `MODE` Field. With the concept of element
59 width overrides being meaningless for CR Fields it is possible to use the
60 `ELWIDTH` field for extra fields.
61
62 Condition Register based operations such as `mfcr` and `crand` can thus
63 be made more flexible. However the rules that apply in this section
64 also apply to future CR-based instructions.
65
66 There are two primary different types of CR operations:
67
68 * Those which have a 3-bit operand field (referring to a CR Field)
69 * Those which have a 5-bit operand (referring to a bit within the
70 whole 32-bit CR)
71
72 Examining these two as has already been done it is observed that the
73 difference may be considered to be that the 5-bit variant provides
74 additional information about which CR Field bit (EQ, GE, LT, SO) is to
75 be operated on by the instruction.
76
77 Thus, logically, we may set the following rule:
78
79 * When a 5-bit CR Result field is used in an instruction, the
80 `inv, VLi and RC1` variant of Data-Dependent Fail-First
81 must be used. i.e. the bit of the CR field to be tested is
82 the one that has just been modified by the operation.
83 * When a 3-bit CR Result field is used the `inv CRbit` variant
84 must be used in order to select which CR Field bit shall
85 be tested (EQ, LE, GE, SO)
86
87 The reason why the 3-bit CR variant needs the additional CR-bit
88 field should be obvious from the fact that the 3-bit CR Field
89 from the base Power ISA v3.0B operation clearly does not contain
90 and is missing the two CR Field Selector bits. Thus, these two
91 bits (to select EQ, LE, GE or SO) must be provided in another
92 way.
93
94 Examples of the former type:
95
96 * crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
97 to be tested against `inv` is the one selected by `BT`
98 * mcrf. This has only 3-bit (BF, BFA). In order to select the
99 bit to be tested, the alternative FFirst encoding must be used.
100
101 This limits sv.mcrf in that it may not use the `VLi` (VL inclusive)
102 Mode. This is unfortunste but unavoidable due to encoding pressure
103 on SVP64.
104
105 # Predicate-result Condition Register operations
106
107 These are again slightly different compared to SVP64 arithmetic
108 pred-result (described in [[svp64/appendix]]). The reason is that,
109 again, for arithmetic operations the production of a CR Field when
110 Rc=1 is a *co-result* accompanying the main arithmetic result, whereas
111 for CR-based operations the CR Field or CR bit *is* itself the result
112 of the operation.
113
114 Therefore, logically, Predicate-result needs to be adapted to
115 test the actual result of the CR-based instruction, rather than
116 test the co-resultant CR when Rc=1.
117
118 for i in range(VL):
119 # predication test, skip all masked out elements.
120 # skips when sz=0
121 if predicate_masked_out(i):
122 continue
123 # result is to go into CR. may be a 4-bit CR Field
124 # (3-bit mode) or just a single bit (5-bit mode)
125 result = op(...)
126 # obtain CRbit from BA result operand field,
127 # if this CR op has 5-bit CR result operands
128 if 5bit mode:
129 CRbit = BA[3:4]
130 # now test CR, similar to branch
131 if CRnew[CRbit] != inv:
132 continue # test failed: cancel store
133 # result optionally stored
134 update_CR(result)