(no commit message)
[libreriscv.git] / openpower / sv / normal.mdwn
1 [[!tag standards]]
2
3 # Normal Mode for SVP64
4
5 * <https://bugs.libre-soc.org/show_bug.cgi?id=574>
6 * <https://bugs.libre-soc.org/show_bug.cgi?id=558#c47>
7 * [[svp64]]
8
9 Normal SVP64 Mode covers Arithmetic and Logical operations
10 to provide suitable additional behaviour. The Mode
11 field is bits 19-23 of the [[svp64]] RM Field.
12
13 Table of contents:
14
15 [[!toc]]
16
17 # Mode
18
19 Mode is an augmentation of SV behaviour, providing additional
20 functionality. Some of these alterations are element-based (saturation), others involve post-analysis (predicate result) and others are Vector-based (mapreduce, fail-on-first).
21
22 [[sv/ldst]],
23 [[sv/cr_ops]] and [[sv/branches]] are covered separately: the following
24 Modes apply to Arithmetic and Logical SVP64 operations:
25
26 * **normal** mode is straight vectorisation. no augmentations: the vector comprises an array of independently created results.
27 * **ffirst** or data-dependent fail-on-first: see separate section. the vector may be truncated depending on certain criteria.
28 *VL is altered as a result*.
29 * **sat mode** or saturation: clamps each element result to a min/max rather than overflows / wraps. allows signed and unsigned clamping for both INT
30 and FP.
31 * **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 [[svp64/appendix]]
32 note that there are comprehensive caveats when using this mode.
33 * **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
34 *destination* predicate bit was zero. When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed. See appendix for details.
35
36 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.
37
38 The Mode table for Arithmetic and Logical operations
39 is laid out as follows:
40
41 | 0-1 | 2 | 3 4 | description |
42 | --- | --- |---------|-------------------------- |
43 | 00 | 0 | dz sz | normal mode |
44 | 00 | 1 | 0 RG | scalar reduce mode (mapreduce), SUBVL=1 |
45 | 00 | 1 | 1 / | parallel reduce mode (mapreduce), SUBVL=1 |
46 | 00 | 1 | SVM RG | subvector reduce mode, SUBVL>1 |
47 | 01 | inv | CR-bit | Rc=1: ffirst CR sel |
48 | 01 | inv | VLi RC1 | Rc=0: ffirst z/nonz |
49 | 10 | N | dz sz | sat mode: N=0/1 u/s |
50 | 11 | inv | CR-bit | Rc=1: pred-result CR sel |
51 | 11 | inv | dz RC1 | Rc=0: pred-result z/nonz |
52
53 Fields:
54
55 * **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.
56 * **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)
57 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
58 than the normal 0..VL-1
59 * **SVM** sets "subvector" reduce mode
60 * **N** sets signed/unsigned saturation.
61 * **RC1** as if Rc=1, stores CRs *but not the result*
62 * **VLi** VL inclusive: in fail-first mode, the truncation of
63 VL *includes* the current element at the failure point rather
64 than excludes it from the count.
65
66 For LD/ST Modes, see [[sv/ldst]]. For Condition Registers
67 see [[sv/cr_ops]].
68 For Branch modes, see [[sv/branches]].
69
70 # Rounding, clamp and saturate
71
72 See [[av_opcodes]] for relevant opcodes and use-cases.
73
74 To help ensure that audio quality is not compromised by overflow,
75 "saturation" is provided, as well as a way to detect when saturation
76 occurred if desired (Rc=1). When Rc=1 there will be a *vector* of CRs,
77 one CR per element in the result (Note: this is different from VSX which
78 has a single CR per block).
79
80 When N=0 the result is saturated to within the maximum range of an
81 unsigned value. For integer ops this will be 0 to 2^elwidth-1. Similar
82 logic applies to FP operations, with the result being saturated to
83 maximum rather than returning INF, and the minimum to +0.0
84
85 When N=1 the same occurs except that the result is saturated to the min
86 or max of a signed result, and for FP to the min and max value rather
87 than returning +/- INF.
88
89 When Rc=1, the CR "overflow" bit is set on the CR associated with the
90 element, to indicate whether saturation occurred. Note that due to
91 the hugely detrimental effect it has on parallel processing, XER.SO is
92 **ignored** completely and is **not** brought into play here. The CR
93 overflow bit is therefore simply set to zero if saturation did not occur,
94 and to one if it did.
95
96 Note also that saturate on operations that produce a carry output are
97 prohibited due to the conflicting use of the CR.so bit for storing if
98 saturation occurred.
99
100 Post-analysis of the Vector of CRs to find out if any given element hit
101 saturation may be done using a mapreduced CR op (cror), or by using the
102 new crweird instruction, transferring the relevant CR bits to a scalar
103 integer and testing it for nonzero. see [[sv/cr_int_predication]]
104
105 Note that the operation takes place at the maximum bitwidth (max of
106 src and dest elwidth) and that truncation occurs to the range of the
107 dest elwidth.
108
109 # Reduce mode
110
111 Reduction in SVP64 is similar in essence to other Vector Processing
112 ISAs, but leverages the underlying scalar Base v3.0B operations.
113 Thus it is more a convention that the programmer may utilise to give
114 the appearance and effect of a Horizontal Vector Reduction.
115 Details are in the [[svp64/appendix]]
116
117 # Fail-on-first
118
119 Data-dependent fail-on-first has two distinct variants: one for LD/ST,
120 the other for arithmetic operations (actually, CR-driven). Note in each
121 case the assumption is that vector elements are required appear to be
122 executed in sequential Program Order, element 0 being the first.
123
124 * LD/ST ffirst treats the first LD/ST in a vector (element 0) as an
125 ordinary one. Exceptions occur "as normal". However for elements 1
126 and above, if an exception would occur, then VL is **truncated** to the
127 previous element.
128 * Data-driven (CR-driven) fail-on-first activates when Rc=1 or other
129 CR-creating operation produces a result (including cmp). Similar to
130 branch, an analysis of the CR is performed and if the test fails, the
131 vector operation terminates and discards all element operations at and
132 above the current one, and VL is truncated to either
133 the *previous* element or the current one, depending on whether
134 VLi (VL "inclusive") is set.
135
136 Thus the new VL comprises a contiguous vector of results,
137 all of which pass the testing criteria (equal to zero, less than zero).
138
139 The CR-based data-driven fail-on-first is new and not found in ARM
140 SVE or RVV. It is extremely useful for reducing instruction count,
141 however requires speculative execution involving modifications of VL
142 to get high performance implementations. An additional mode (RC1=1)
143 effectively turns what would otherwise be an arithmetic operation
144 into a type of `cmp`. The CR is stored (and the CR.eq bit tested
145 against the `inv` field).
146 If the CR.eq bit is equal to `inv` then the Vector is truncated and
147 the loop ends.
148 Note that when RC1=1 the result elements are never stored, only the CRs.
149
150 VLi is only available as an option when `Rc=0` (or for instructions
151 which do not have Rc). When set, the current element is always
152 also included in the count (the new length that VL will be set to).
153 This may be useful in combination with "inv" to truncate the Vector
154 to `exclude` elements that fail a test, or, in the case of implementations
155 of strncpy, to include the terminating zero.
156
157 In CR-based data-driven fail-on-first there is only the option to select
158 and test one bit of each CR (just as with branch BO). For more complex
159 tests this may be insufficient. If that is the case, a vectorised crops
160 (crand, cror) may be used, and ffirst applied to the crop instead of to
161 the arithmetic vector.
162
163 One extremely important aspect of ffirst is:
164
165 * LDST ffirst may never set VL equal to zero. This because on the first
166 element an exception must be raised "as normal".
167 * CR-based data-dependent ffirst on the other hand **can** set VL equal
168 to zero. This is the only means in the entirety of SV that VL may be set
169 to zero (with the exception of via the SV.STATE SPR). When VL is set
170 zero due to the first element failing the CR bit-test, all subsequent
171 vectorised operations are effectively `nops` which is
172 *precisely the desired and intended behaviour*.
173
174 CR-based data-dependent first on the other hand MUST not truncate VL
175 arbitrarily to a length decided by the hardware: VL MUST only be
176 truncated based explicitly on whether a test fails.
177 This because it is a precise test on which algorithms
178 will rely.
179
180 ## Data-dependent fail-first on CR operations (crand etc)
181
182 Operations that actually produce or alter CR Field as a result
183 do not also in turn have an Rc=1 mode. However it makes no
184 sense to try to test the 4 bits of a CR Field for being equal
185 or not equal to zero. Moreover, the result is already in the
186 form that is desired: it is a CR field. Therefore,
187 CR-based operations have their own SVP64 Mode, described
188 in [[sv/cr_ops]]
189
190 There are two primary different types of CR operations:
191
192 * Those which have a 3-bit operand field (referring to a CR Field)
193 * Those which have a 5-bit operand (referring to a bit within the
194 whole 32-bit CR)
195
196 More details can be found in [[sv/cr_ops]].
197
198 # pred-result mode
199
200 This mode merges common CR testing with predication, saving on instruction
201 count. Below is the pseudocode excluding predicate zeroing and elwidth
202 overrides. Note that the pseudocode for [[sv/cr_ops]] is slightly different.
203
204 for i in range(VL):
205 # predication test, skip all masked out elements.
206 if predicate_masked_out(i):
207 continue
208 result = op(iregs[RA+i], iregs[RB+i])
209 CRnew = analyse(result) # calculates eq/lt/gt
210 # Rc=1 always stores the CR
211 if Rc=1 or RC1:
212 crregs[offs+i] = CRnew
213 # now test CR, similar to branch
214 if RC1 or CRnew[BO[0:1]] != BO[2]:
215 continue # test failed: cancel store
216 # result optionally stored but CR always is
217 iregs[RT+i] = result
218
219 The reason for allowing the CR element to be stored is so that
220 post-analysis of the CR Vector may be carried out. For example:
221 Saturation may have occurred (and been prevented from updating, by the
222 test) but it is desirable to know *which* elements fail saturation.
223
224 Note that RC1 Mode basically turns all operations into `cmp`. The
225 calculation is performed but it is only the CR that is written. The
226 element result is *always* discarded, never written (just like `cmp`).
227
228 Note that predication is still respected: predicate zeroing is slightly
229 different: elements that fail the CR test *or* are masked out are zero'd.
230