1 # RFC ls010 SVP64 Zero-Overhead Loop Prefix Subsystem
3 Credits and acknowledgements:
11 * NLnet Foundation, for funding
12 * OpenPOWER Foundation
15 * IBM for the Power ISA itself
19 * <https://bugs.libre-soc.org/show_bug.cgi?id=1045>
23 Simple-V is a type of Vectorisation best described as a "Prefix Loop
24 Subsystem" similar to the 5 decades-old Zilog Z80 `LDIR` instruction and
25 to the 8086 `REP` Prefix instruction. More advanced features are similar
26 to the Z80 `CPIR` instruction. If viewed one-dimensionally as an actual
27 Vector ISA it introduces over 1.5 million 64-bit Vector instructions.
28 SVP64, the instruction format used by Simple-V, is therefore best viewed
29 as an orthogonal RISC-paradigm "Prefixing" subsystem instead.
31 Except where explicitly stated all bit numbers remain as in the rest of
32 the Power ISA: in MSB0 form (the bits are numbered from 0 at the MSB on
33 the left and counting up as you move rightwards to the LSB end). All bit
34 ranges are inclusive (so `4:6` means bits 4, 5, and 6, in MSB0 order).
35 **All register numbering and element numbering however is LSB0 ordering**
36 which is a different convention from that used elsewhere in the Power ISA.
38 The SVP64 prefix always comes before the suffix in PC order and must be
39 considered an independent "Defined word" that augments the behaviour of
40 the following instruction, but does **not** change the actual Decoding
41 of that following instruction. **All prefixed instructions retain their
42 non-prefixed encoding and definition**.
44 Two apparent exceptions to the above hard rule exist: SV Branch-Conditional
45 operations and LD/ST-update "Post-Increment" Mode. Post-Increment
46 was considered sufficiently high priority (significantly reducing hot-loop
47 instruction count) that one bit in the Prefix is reserved for it.
48 Vectorised Branch-Conditional operations "embed" the original Scalar
49 Branch-Conditional behaviour into a much more advanced variant that
50 is highly suited to High-Performance Computation (HPC), Supercomputing,
51 and parallel GPU Workloads.
53 *Architectural Resource Allocation note: it is prohibited to accept RFCs
54 which fundamentally violate this hard requirement. Under no circumstances
55 must the Suffix space have an alternate instruction encoding allocated
56 within SVP64 that is entirely different from the non-prefixed Defined
57 Word. Hardware Implementors critically rely on this inviolate guarantee
58 to implement High-Performance Multi-Issue micro-architectures that can
59 sustain 100% throughput*
61 Subset implementations in hardware are permitted, as long as certain
62 rules are followed, allowing for full soft-emulation including future
63 revisions. Compliancy Subsets exist to ensure minimum levels of binary
64 interoperability expectations within certain environments.
66 ## SVP64 encoding features
68 A number of features need to be compacted into a very small space of
71 * Independent per-register Scalar/Vector tagging and range extension on
73 * Element width overrides on both source and destination
74 * Predication on both source and destination
75 * Two different sources of predication: INT and CR Fields
76 * SV Modes including saturation (for Audio, Video and DSP), mapreduce,
77 fail-first and predicate-result mode.
79 Different classes of operations require different formats. The earlier
80 sections cover the common formats and the four separate modes follow:
81 CR operations (crops), Arithmetic/Logical (termed "normal"), Load/Store
82 and Branch-Conditional.
84 ## Definition of Reserved in this spec.
86 For the new fields added in SVP64, instructions that have any of their
87 fields set to a reserved value must cause an illegal instruction trap,
88 to allow emulation of future instruction sets, or for subsets of SVP64 to
89 be implemented in hardware and the rest emulated. This includes SVP64
90 SPRs: reading or writing values which are not supported in hardware
91 must also raise illegal instruction traps in order to allow emulation.
92 Unless otherwise stated, reserved values are always all zeros.
94 This is unlike OpenPower ISA v3.1, which in many instances does not
95 require a trap if reserved fields are nonzero. Where the standard Power
96 ISA definition is intended the red keyword `RESERVED` is used.
98 ## Definition of "UnVectoriseable"
100 Any operation that inherently makes no sense if repeated is termed
101 "UnVectoriseable" or "UnVectorised". Examples include `sc` or `sync`
102 which have no registers. `mtmsr` is also classed as UnVectoriseable
103 because there is only one `MSR`.
105 ## Register files, elements, and Element-width Overrides
107 In the Upper Compliancy Levels of SVP64 the size of the GPR and FPR
108 Register files are expanded from 32 to 128 entries, and the number of
109 CR Fields expanded from CR0-CR7 to CR0-CR127. (Note: A future version
110 of SVP64 is anticipated to extend the VSR register file).
112 Memory access remains exactly the same: the effects of `MSR.LE` remain
113 exactly the same, affecting as they already do and remain **only**
114 on the Load and Store memory-register operation byte-order, and having
115 nothing to do with the ordering of the contents of register files or
116 register-register operations.
118 To be absolutely clear:
121 There are no conceptual arithmetic ordering or other changes over the
122 Scalar Power ISA definitions to registers or register files or to
123 arithmetic or Logical Operations beyond element-width subdivision
127 numbering is naturally **LSB0-sequentially-incrementing from zero, not
128 MSB0-incrementing** including when element-width overrides are used,
129 at which point the elements progress through each register
130 sequentially from the LSB end
131 (confusingly numbered the highest in MSB0 ordering) and progress
132 incrementally to the MSB end (confusingly numbered the lowest in
135 When exclusively using MSB0-numbering, SVP64
136 becomes unnecessarily complex to both express and subsequently understand:
137 the required conditional subtractions from 63,
138 31, 15 and 7 needed to express the fact that elements are LSB0-sequential
139 unfortunately become a hostile minefield, obscuring both
140 intent and meaning. Therefore for the
141 purposes of this section the more natural **LSB0 numbering is assumed**
142 and it is left to the reader to translate to MSB0 numbering.
144 The Canonical specification for how element-sequential numbering and
145 element-width overrides is defined is expressed in the following c
146 structure, assuming a Little-Endian system, and naturally using LSB0
147 numbering everywhere because the ANSI c specification is inherently LSB0.
148 Note the deliberate similarity to how VSX register elements are defined:
153 uint8_t bytes[]; // elwidth 8
154 uint16_t hwords[]; // elwidth 16
155 uint32_t words[]; // elwidth 32
156 uint64_t dwords[]; // elwidth 64
157 uint8_t actual_bytes[8];
160 elreg_t int_regfile[128];
162 void get_register_element(el_reg_t* el, int gpr, int element, int width) {
164 case 64: el->dwords[0] = int_regfile[gpr].dwords[element];
165 case 32: el->words[0] = int_regfile[gpr].words[element];
166 case 16: el->hwords[0] = int_regfile[gpr].hwords[element];
167 case 8 : el->bytes[0] = int_regfile[gpr].bytes[element];
170 void set_register_element(el_reg_t* el, int gpr, int element, int width) {
172 case 64: int_regfile[gpr].dwords[element] = el->dwords[0];
173 case 32: int_regfile[gpr].words[element] = el->words[0];
174 case 16: int_regfile[gpr].hwords[element] = el->hwords[0];
175 case 8 : int_regfile[gpr].bytes[element] = el->bytes[0];
180 Example Vector-looped add operation implementation when elwidths are 64-bit:
183 # vector-add RT, RA,RB using the "uint64_t" union member, "dwords"
185 int_regfile[RT].dword[i] = int_regfile[RA].dword[i] + int_regfile[RB].dword[i]
188 However if elwidth overrides are set to 16 for both source and destination:
191 # vector-add RT, RA, RB using the "uint64_t" union member "halfs"
193 int_regfile[RT].halfs[i] = int_regfile[RA].halfs[i] + int_regfile[RB].halfs[i]
196 Hardware Architectural note: to avoid a Read-Modify-Write at the register
197 file it is strongly recommended to implement byte-level write-enable lines
198 exactly as has been implemented in DRAM ICs for many decades. Additionally
199 the predicate mask bit is advised to be associated with the element
200 operation and alongside the result ultimately passed to the register file.
201 When element-width is set to 64-bit the relevant predicate mask bit
202 may be repeated eight times and pull all eight write-port byte-level
203 lines HIGH. Clearly when element-width is set to 8-bit the relevant
204 predicate mask bit corresponds directly with one single byte-level
205 write-enable line. It is up to the Hardware Architect to then amortise
206 (merge) elements together into both PredicatedSIMD Pipelines as well
207 as simultaneous non-overlapping Register File writes, to achieve High
210 **Comparative equivalent using VSR registers**
212 For a comparative data point the VSR Registers may be expressed in the
213 same fashion. The c code below is directly an expression of Figure 97 in
214 Power ISA Public v3.1 Book I Section 6.3 page 258, *after compensating for
215 MSB0 numbering in both bits and elements, adapting in full to LSB0 numbering,
216 and obeying LE ordering*.
218 **Crucial to understanding why the subtraction from 1,3,7,15 is present
219 is because VSX Registers number elements also in MSB0 order**. SVP64
220 very specifically numbers elements in **LSB0** order with the first
221 element being at the **LSB** end of the register, where VSX places
222 the numerically-lowest element at the **MSB** end of the register.
227 uint8_t bytes[16]; // elwidth 8, QTY 16 FIXED total
228 uint16_t hwords[8]; // elwidth 16, QTY 8 FIXED total
229 uint32_t words[4]; // elwidth 32, QTY 8 FIXED total
230 uint64_t dwords[2]; // elwidth 64, QTY 2 FIXED total
231 uint8_t actual_bytes[16]; // totals 128-bit
234 elreg_t VSR_regfile[64];
236 static void check_num_elements(int elt, int width) {
238 case 64: assert elt < 2;
239 case 32: assert elt < 4;
240 case 16: assert elt < 8;
241 case 8 : assert elt < 16;
244 void get_VSR_element(el_reg_t* el, int gpr, int elt, int width) {
245 check_num_elements(elt, width);
247 case 64: el->dwords[0] = VSR_regfile[gpr].dwords[1-elt];
248 case 32: el->words[0] = VSR_regfile[gpr].words[3-elt];
249 case 16: el->hwords[0] = VSR_regfile[gpr].hwords[7-elt];
250 case 8 : el->bytes[0] = VSR_regfile[gpr].bytes[15-elt];
253 void set_VSR_element(el_reg_t* el, int gpr, int elt, int width) {
254 check_num_elements(elt, width);
256 case 64: VSR_regfile[gpr].dwords[1-elt] = el->dwords[0];
257 case 32: VSR_regfile[gpr].words[3-elt] = el->words[0];
258 case 16: VSR_regfile[gpr].hwords[7-elt] = el->hwords[0];
259 case 8 : VSR_regfile[gpr].bytes[15-elt] = el->bytes[0];
264 For VSR Registers one key difference is that the overlay of different element
265 widths is clearly a *bounded static quantity*, whereas for Simple-V the
267 unrestrained and permitted to flow into *successive underlying Scalar registers*.
268 This difference is absolutely critical to a full understanding of the entire
269 Simple-V paradigm and why element-ordering, bit-numbering *and register numbering*
270 are all so strictly defined.
272 Implementations are not permitted to violate the Canonical definition. Software
273 will be critically relying on the wrapped (overflow) behaviour inherently
274 implied by the unbounded variable-length c arrays.
276 Illustrating the exact same loop with the exact same effect as achieved by Simple-V
277 we are first forced to create wrapper functions, to cater for the fact
278 that VSR register elements are static bounded:
281 int calc_VSR_reg_offs(int elt, int width) {
283 case 64: return floor(elt / 2);
284 case 32: return floor(elt / 4);
285 case 16: return floor(elt / 8);
286 case 8 : return floor(elt / 16);
289 int calc_VSR_elt_offs(int elt, int width) {
291 case 64: return (elt % 2);
292 case 32: return (elt % 4);
293 case 16: return (elt % 8);
294 case 8 : return (elt % 16);
297 void _set_VSR_element(el_reg_t* el, int gpr, int elt, int width) {
298 int new_elt = calc_VSR_elt_offs(elt, width);
299 int new_reg = calc_VSR_reg_offs(elt, width);
300 set_VSR_element(el, gpr+new_reg, new_elt, width);
304 And finally use these functions:
307 # VSX-add RT, RA, RB using the "uint64_t" union member "halfs"
309 el_reg_t result, ra, rb;
310 _get_VSR_element(&ra, RA, i, 16);
311 _get_VSR_element(&rb, RB, i, 16);
312 result.halfs[0] = ra.halfs[0] + rb.halfs[0]; // use array 0 elements
313 _set_VSR_element(&result, RT, i, 16);
317 ## Scalar Identity Behaviour
319 SVP64 is designed so that when the prefix is all zeros, and VL=1, no
320 effect or influence occurs (no augmentation) such that all standard Power
321 ISA v3.0/v3.1 instructions covered by the prefix are "unaltered". This
322 is termed `scalar identity behaviour` (based on the mathematical
323 definition for "identity", as in, "identity matrix" or better "identity
326 Note that this is completely different from when VL=0. VL=0 turns all
327 operations under its influence into `nops` (regardless of the prefix)
328 whereas when VL=1 and the SV prefix is all zeros, the operation simply
329 acts as if SV had not been applied at all to the instruction (an
330 "identity transformation").
332 The fact that `VL` is dynamic and can be set to any value at runtime based
333 on program conditions and behaviour means very specifically that
334 `scalar identity behaviour` is **not** a redundant encoding. If the
335 only means by which VL could be set was by way of static-compiled
336 immediates then this assertion would be false. VL should not
337 be confused with MAXVL when understanding this key aspect of SimpleV.
339 ## Register Naming and size
341 As indicated above SV Registers are simply the GPR, FPR and CR
342 register files extended linearly to larger sizes; SV Vectorisation
343 iterates sequentially through these registers (LSB0 sequential ordering
346 Where the integer regfile in standard scalar Power ISA v3.0B/v3.1B is
347 r0 to r31, SV extends this as r0 to r127. Likewise FP registers are
348 extended to 128 (fp0 to fp127), and CR Fields are extended to 128 entries,
351 The names of the registers therefore reflects a simple linear extension
352 of the Power ISA v3.0B / v3.1B register naming, and in hardware this
353 would be reflected by a linear increase in the size of the underlying
354 SRAM used for the regfiles.
356 Note: when an EXTRA field (defined below) is zero, SV is deliberately
357 designed so that the register fields are identical to as if SV was not in
358 effect i.e. under these circumstances (EXTRA=0) the register field names
359 RA, RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers.
360 This is part of `scalar identity behaviour` described above.
362 **Condition Register(s)**
364 The Scalar Power ISA Condition Register is a 64 bit register where the top
365 32 MSBs (numbered 0:31 in MSB0 numbering) are not used. This convention is
367 in SVP64 and an additional 15 Condition Registers provided in
368 order to store the new CR Fields, CR8-CR15, CR16-CR23 etc. sequentially.
369 The top 32 MSBs in each new SVP64 Condition Register are *also* not used:
370 only the bottom 32 bits (numbered 32:63 in MSB0 numbering).
372 *Programmer's note: using `sv.mfcr` without element-width overrides
373 to take into account the fact that the top 32 MSBs are zero and thus
374 effectively doubling the number of GPR registers required to hold all 128
375 CR Fields would seem the only option because normally elwidth overrides
376 would halve the capacity of the instruction. However in this case it
377 is possible to use destination element-width overrides (for `sv.mfcr`.
378 source overrides would be used on the GPR of `sv.mtocrf`), whereupon
379 truncation of the 64-bit Condition Register(s) occurs, throwing away
380 the zeros and storing the remaining (valid, desired) 32-bit values
381 sequentially into (LSB0-convention) lower-numbered and upper-numbered
382 halves of GPRs respectively. The programmer is expected to be aware
383 however that the full width of the entire 64-bit Condition Register
384 is considered to be "an element". This is **not** like any other
385 Condition-Register instructions because all other CR instructions,
386 on closer investigation, will be observed to all be CR-bit or CR-Field
387 related. Thus a `VL` of 16 must be used*
391 With the way that EXTRA fields are defined and applied to register fields,
392 future versions of SV may involve 256 or greater registers. Backwards
393 binary compatibility may be achieved with a PCR bit (Program Compatibility
394 Register) or an MSR bit analogous to SF.
395 Further discussion is out of scope for this version of SVP64.
397 Additionally, a future variant of SVP64 will be applied to the Scalar
398 (Quad-precision and 128-bit) VSX instructions. Element-width overrides
399 are an opportunity to expand a future version of the Power ISA
400 to 256-bit, 512-bit and
401 1024-bit operations, as well as doubling or quadrupling the number
402 of VSX registers to 128 or 256. Again further discussion is out of
403 scope for this version of SVP64.
409 # New 64-bit Instruction Encoding spaces
411 The following seven new areas are defined within Primary Opcode 9 (EXT009)
412 as a new 64-bit encoding space, alongside Primary Opcode 1
415 | 0-5 | 6 | 7 | 8-31 | 32| Description |
416 |-----|---|---|-------|---|------------------------------------|
417 | PO | 0 | x | xxxx | 0 | `RESERVED2` (57-bit) |
418 | PO | 0 | 0 | !zero | 1 | SVP64Single:EXT232-263, or `RESERVED3` |
419 | PO | 0 | 0 | 0000 | 1 | Scalar EXT232-263 |
420 | PO | 0 | 1 | nnnn | 1 | SVP64:EXT232-263 |
421 | PO | 1 | 0 | 0000 | x | `RESERVED1` (32-bit) |
422 | PO | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
423 | PO | 1 | 1 | nnnn | n | SVP64:EXT000-063 |
425 Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
426 it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
427 for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
428 prohibition allows SVP64Single to share its Encoding space with Scalar
429 Ext232-263 and Scalar EXT300-363.
431 Also that RESERVED1 and 2 are candidates for future Major opcode
432 areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
433 they may equally be allocated entirely differently.
435 *Architectural Resource Allocation Note: **under no circumstances** must
436 different Defined Words be allocated within any `EXT{z}` prefixed
437 or unprefixed space for a given value of `z`. Even if UnVectoriseable
438 an instruction Defined Word space must have the exact same Instruction
439 and exact same Instruction Encoding in all spaces (including
440 being RESERVED if UnVectoriseable) or not be allocated at all.
441 This is required as an inviolate hard rule governing Primary Opcode 9
442 that may not be revoked under any circumstances. A useful way to think
443 of this is that the Prefix Encoding is, like the 8086 REP instruction,
444 an independent 32-bit Defined Word. The only semi-exceptions are
445 the Post-Increment Mode of LD/ST-Update and Vectorised Branch-Conditional.*
447 Encoding spaces and their potential are illustrated:
449 | Encoding | Available bits | Scalar | Vectoriseable | SVP64Single |
450 |----------|----------------|--------|---------------|--------------|
451 |EXT000-063| 32 | yes | yes |yes |
452 |EXT100-163| 64 | yes | no |no |
453 |R3SERVED2 | 57 | N/A |not applicable |not applicable|
454 |EXT232-263| 32 | yes | yes |yes |
455 |RESERVED1 | 32 | N/A | no |no |
459 * Prefixed-Prefixed (96-bit) instructions are prohibited. EXT1xx is
460 thus inherently UnVectoriseable as the EXT1xx prefix is 32-bit
461 on top of an SVP64 prefix which is 32-bit on top of a Defined Word
462 and the complexity at the Decoder becomes too great for High
463 Performance Multi-Issue systems.
464 * RESERVED2 presently remains unallocated as of yet and therefore its
465 potential is not yet defined (Not Applicable).
466 * RESERVED1 is also unallocated at present, but it is known in advance
467 that the area is UnVectoriseable and also cannot be Prefixed with
469 * Considerable care is needed both on Architectural Resource Allocation
470 as well as instruction design itself. Once an instruction is allocated
471 in an UnVectoriseable area it can never be Vectorised without providing
472 an entirely new Encoding.
474 # Remapped Encoding (`RM[0:23]`)
476 In the SVP64 Vector Prefix spaces, the 24 bits 8-31 are termed `RM`. Bits
477 32-37 are the Primary Opcode of the Suffix "Defined Word". 38-63 are the
478 remainder of the Defined Word. Note that the new EXT232-263 SVP64 area
479 it is obviously mandatory that bit 32 is required to be set to 1.
481 | 0-5 | 6 | 7 | 8-31 | 32-37 | 38-64 |Description |
482 |-----|---|---|----------|--------|----------|-----------------------|
483 | PO | 0 | 1 | RM[0:23] | 1nnnnn | xxxxxxxx | SVP64:EXT232-263 |
484 | PO | 1 | 1 | RM[0:23] | nnnnnn | xxxxxxxx | SVP64:EXT000-063 |
486 It is important to note that unlike v3.1 64-bit prefixed instructions
487 there is insufficient space in `RM` to provide identification of
488 any SVP64 Fields without first partially decoding the 32-bit suffix.
489 Similar to the "Forms" (X-Form, D-Form) the `RM` format is individually
490 associated with every instruction. However this still does not adversely
491 affect Multi-Issue Decoding because the identification of the *length*
492 of anything in the 64-bit space has been kept brutally simple (EXT009),
493 and further decoding of any number of 64-bit Encodings in parallel at
494 that point is fully independent.
496 Extreme caution and care must be taken when extending SVP64
497 in future, to not create unnecessary relationships between prefix and
498 suffix that could complicate decoding, adding latency.
502 The following fields are common to all Remapped Encodings:
504 | Field Name | Field bits | Description |
505 |------------|------------|----------------------------------------|
506 | MASKMODE | `0` | Execution (predication) Mask Kind |
507 | MASK | `1:3` | Execution Mask |
508 | SUBVL | `8:9` | Sub-vector length |
510 The following fields are optional or encoded differently depending
511 on context after decoding of the Scalar suffix:
513 | Field Name | Field bits | Description |
514 |------------|------------|----------------------------------------|
515 | ELWIDTH | `4:5` | Element Width |
516 | ELWIDTH_SRC | `6:7` | Element Width for Source |
517 | EXTRA | `10:18` | Register Extra encoding |
518 | MODE | `19:23` | changes Vector behaviour |
520 * MODE changes the behaviour of the SV operation (result saturation,
522 * SUBVL groups elements together into vec2, vec3, vec4 for use in 3D
523 and Audio/Video DSP work
524 * ELWIDTH and ELWIDTH_SRC overrides the instruction's destination and
526 * MASK (and MASK_SRC) and MASKMODE provide predication (two types of
527 sources: scalar INT and Vector CR).
528 * Bits 10 to 18 (EXTRA) are further decoded depending on the RM category
529 for the instruction, which is determined only by decoding the Scalar 32
532 Similar to Power ISA `X-Form` etc. EXTRA bits are given designations,
533 such as `RM-1P-3S1D` which indicates for this example that the operation
534 is to be single-predicated and that there are 3 source operand EXTRA
535 tags and one destination operand tag.
537 Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance
538 or increased latency in some implementations due to lane-crossing.
542 Mode is an augmentation of SV behaviour. Different types of instructions
543 have different needs, similar to Power ISA v3.1 64 bit prefix 8LS and MTRR
544 formats apply to different instruction types. Modes include Reduction,
545 Iteration, arithmetic saturation, and Fail-First. More specific details
546 in each section and in the SVP64 appendix
548 * For condition register operations see [[sv/cr_ops]]
549 * For LD/ST Modes, see [[sv/ldst]].
550 * For Branch modes, see [[sv/branches]]
551 * For arithmetic and logical, see [[sv/normal]]
555 Default behaviour is set to 0b00 so that zeros follow the convention
556 of `scalar identity behaviour`. In this case it means that elwidth
557 overrides are not applicable. Thus if a 32 bit instruction operates
558 on 32 bit, `elwidth=0b00` specifies that this behaviour is unmodified.
559 Likewise when a processor is switched from 64 bit to 32 bit mode,
560 `elwidth=0b00` states that, again, the behaviour is not to be modified.
562 Only when elwidth is nonzero is the element width overridden to the
563 explicitly required value.
565 ### Elwidth for Integers:
567 | Value | Mnemonic | Description |
568 |-------|----------------|------------------------------------|
569 | 00 | DEFAULT | default behaviour for operation |
570 | 01 | `ELWIDTH=w` | Word: 32-bit integer |
571 | 10 | `ELWIDTH=h` | Halfword: 16-bit integer |
572 | 11 | `ELWIDTH=b` | Byte: 8-bit integer |
574 This encoding is chosen such that the byte width may be computed as
577 ### Elwidth for FP Registers:
579 | Value | Mnemonic | Description |
580 |-------|----------------|------------------------------------|
581 | 00 | DEFAULT | default behaviour for FP operation |
582 | 01 | `ELWIDTH=f32` | 32-bit IEEE 754 Single floating-point |
583 | 10 | `ELWIDTH=f16` | 16-bit IEEE 754 Half floating-point |
584 | 11 | `ELWIDTH=bf16` | Reserved for `bf16` |
587 [`bf16`](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
588 is reserved for a future implementation of SV
590 Note that any IEEE754 FP operation in Power ISA ending in "s" (`fadds`)
591 shall perform its operation at **half** the ELWIDTH then padded back out
592 to ELWIDTH. `sv.fadds/ew=f32` shall perform an IEEE754 FP16 operation
593 that is then "padded" to fill out to an IEEE754 FP32. When ELWIDTH=DEFAULT
594 clearly the behaviour of `sv.fadds` is performed at 32-bit accuracy
595 then padded back out to fit in IEEE754 FP64, exactly as for Scalar
596 v3.0B "single" FP. Any FP operation ending in "s" where ELWIDTH=f16 or
597 ELWIDTH=bf16 is reserved and must raise an illegal instruction (IEEE754
598 FP8 or BF8 are not defined).
600 ### Elwidth for CRs (no meaning)
602 Element-width overrides for CR Fields has no meaning. The bits
603 are therefore used for other purposes, or when Rc=1, the Elwidth
604 applies to the result being tested (a GPR or FPR), but not to the
609 The default for SUBVL is 1 and its encoding is 0b00 to indicate that
610 SUBVL is effectively disabled (a SUBVL for-loop of only one element). this
611 lines up in combination with all other "default is all zeros" behaviour.
613 | Value | Mnemonic | Subvec | Description |
614 |-------|-----------|---------|------------------------|
615 | 00 | `SUBVL=1` | single | Sub-vector length of 1 |
616 | 01 | `SUBVL=2` | vec2 | Sub-vector length of 2 |
617 | 10 | `SUBVL=3` | vec3 | Sub-vector length of 3 |
618 | 11 | `SUBVL=4` | vec4 | Sub-vector length of 4 |
620 The SUBVL encoding value may be thought of as an inclusive range of a
621 sub-vector. SUBVL=2 represents a vec2, its encoding is 0b01, therefore
622 this may be considered to be elements 0b00 to 0b01 inclusive.
624 ## MASK/MASK_SRC & MASKMODE Encoding
626 One bit (`MASKMODE`) indicates the mode: CR or Int predication. The two
627 types may not be mixed.
629 Special note: to disable predication this field must be set to zero in
630 combination with Integer Predication also being set to 0b000. this has the
631 effect of enabling "all 1s" in the predicate mask, which is equivalent to
632 "not having any predication at all" and consequently, in combination with
633 all other default zeros, fully disables SV (`scalar identity behaviour`).
635 `MASKMODE` may be set to one of 2 values:
637 | Value | Description |
638 |-----------|------------------------------------------------------|
639 | 0 | MASK/MASK_SRC are encoded using Integer Predication |
640 | 1 | MASK/MASK_SRC are encoded using CR-based Predication |
642 Integer Twin predication has a second set of 3 bits that uses the same
643 encoding thus allowing either the same register (r3, r10 or r31) to be
644 used for both src and dest, or different regs (one for src, one for dest).
646 Likewise CR based twin predication has a second set of 3 bits, allowing
647 a different test to be applied.
649 Note that it is assumed that Predicate Masks (whether INT or CR) are
650 read *before* the operations proceed. In practice (for CR Fields)
651 this creates an unnecessary block on parallelism. Therefore, it is up
652 to the programmer to ensure that the CR fields used as Predicate Masks
653 are not being written to by any parallel Vector Loop. Doing so results
654 in **UNDEFINED** behaviour, according to the definition outlined in the
655 Power ISA v3.0B Specification.
657 Hardware Implementations are therefore free and clear to delay reading
658 of individual CR fields until the actual predicated element operation
659 needs to take place, safe in the knowledge that no programmer will have
660 issued a Vector Instruction where previous elements could have overwritten
661 (destroyed) not-yet-executed CR-Predicated element operations.
663 ### Integer Predication (MASKMODE=0)
665 When the predicate mode bit is zero the 3 bits are interpreted as below.
666 Twin predication has an identical 3 bit field similarly encoded.
668 `MASK` and `MASK_SRC` may be set to one of 8 values, to provide the
671 | Value | Mnemonic | Element `i` enabled if: |
672 |-------|----------|------------------------------|
673 | 000 | ALWAYS | predicate effectively all 1s |
674 | 001 | 1 << R3 | `i == R3` |
675 | 010 | R3 | `R3 & (1 << i)` is non-zero |
676 | 011 | ~R3 | `R3 & (1 << i)` is zero |
677 | 100 | R10 | `R10 & (1 << i)` is non-zero |
678 | 101 | ~R10 | `R10 & (1 << i)` is zero |
679 | 110 | R30 | `R30 & (1 << i)` is non-zero |
680 | 111 | ~R30 | `R30 & (1 << i)` is zero |
682 r10 and r30 are at the high end of temporary and unused registers,
683 so as not to interfere with register allocation from ABIs.
685 ### CR-based Predication (MASKMODE=1)
687 When the predicate mode bit is one the 3 bits are interpreted as below.
688 Twin predication has an identical 3 bit field similarly encoded.
690 `MASK` and `MASK_SRC` may be set to one of 8 values, to provide the
693 | Value | Mnemonic | Element `i` is enabled if |
694 |-------|----------|--------------------------|
695 | 000 | lt | `CR[offs+i].LT` is set |
696 | 001 | nl/ge | `CR[offs+i].LT` is clear |
697 | 010 | gt | `CR[offs+i].GT` is set |
698 | 011 | ng/le | `CR[offs+i].GT` is clear |
699 | 100 | eq | `CR[offs+i].EQ` is set |
700 | 101 | ne | `CR[offs+i].EQ` is clear |
701 | 110 | so/un | `CR[offs+i].FU` is set |
702 | 111 | ns/nu | `CR[offs+i].FU` is clear |
704 `offs` is defined as CR32 (4x8) so as to mesh cleanly with Vectorised
705 Rc=1 operations (see below). Rc=1 operations start from CR8 (TBD).
707 The CR Predicates chosen must start on a boundary that Vectorised CR
708 operations can access cleanly, in full. With EXTRA2 restricting starting
709 points to multiples of 8 (CR0, CR8, CR16...) both Vectorised Rc=1 and
710 CR Predicate Masks have to be adapted to fit on these boundaries as well.
712 ## Extra Remapped Encoding <a name="extra_remap"> </a>
714 Shows all instruction-specific fields in the Remapped Encoding
715 `RM[10:18]` for all instruction variants. Note that due to the very
716 tight space, the encoding mode is *not* included in the prefix itself.
717 The mode is "applied", similar to Power ISA "Forms" (X-Form, D-Form)
718 on a per-instruction basis, and, like "Forms" are given a designation
719 (below) of the form `RM-nP-nSnD`. The full list of which instructions
720 use which remaps is here [[opcode_regs_deduped]].
722 **Please note the following**:
725 Machine-readable CSV files have been provided which will make the task
726 of creating SV-aware ISA decoders, documentation, assembler tools
727 compiler tools Simulators documentation all aspects of SVP64 easier
728 and less prone to mistakes. Please avoid manual re-creation of
729 information from the written specification wording, and use the
730 CSV files or use the Canonical tool which creates the CSV files,
731 named sv_analysis.py. The information contained within sv_analysis.py
732 is considered to be part of this Specification, even encoded as it
736 The mappings are part of the SVP64 Specification in exactly the same
737 way as X-Form, D-Form. New Scalar instructions added to the Power ISA
738 will need a corresponding SVP64 Mapping, which can be derived by-rote
739 from examining the Register "Profile" of the instruction.
741 There are two categories: Single and Twin Predication. Due to space
742 considerations further subdivision of Single Predication is based on
743 whether the number of src operands is 2 or 3. With only 9 bits available
744 some compromises have to be made.
746 * `RM-1P-3S1D` Single Predication dest/src1/2/3, applies to 4-operand
747 instructions (fmadd, isel, madd).
748 * `RM-1P-2S1D` Single Predication dest/src1/2 applies to 3-operand
749 instructions (src1 src2 dest)
750 * `RM-2P-1S1D` Twin Predication (src=1, dest=1)
751 * `RM-2P-2S1D` Twin Predication (src=2, dest=1) primarily for LDST (Indexed)
752 * `RM-2P-1S2D` Twin Predication (src=1, dest=2) primarily for LDST Update
756 | Field Name | Field bits | Description |
757 |------------|------------|----------------------------------------|
758 | Rdest\_EXTRA2 | `10:11` | extends Rdest (R\*\_EXTRA2 Encoding) |
759 | Rsrc1\_EXTRA2 | `12:13` | extends Rsrc1 (R\*\_EXTRA2 Encoding) |
760 | Rsrc2\_EXTRA2 | `14:15` | extends Rsrc2 (R\*\_EXTRA2 Encoding) |
761 | Rsrc3\_EXTRA2 | `16:17` | extends Rsrc3 (R\*\_EXTRA2 Encoding) |
762 | EXTRA2_MODE | `18` | used by `divmod2du` and `maddedu` for RS |
764 These are for 3 operand in and either 1 or 2 out instructions.
765 3-in 1-out includes `madd RT,RA,RB,RC`. (DRAFT) instructions
766 such as `maddedu` have an implicit second destination, RS, the
767 selection of which is determined by bit 18.
771 | Field Name | Field bits | Description |
772 |------------|------------|-------------------------------------------|
773 | Rdest\_EXTRA3 | `10:12` | extends Rdest |
774 | Rsrc1\_EXTRA3 | `13:15` | extends Rsrc1 |
775 | Rsrc2\_EXTRA3 | `16:18` | extends Rsrc3 |
777 These are for 2 operand 1 dest instructions, such as `add RT, RA,
778 RB`. However also included are unusual instructions with an implicit
779 dest that is identical to its src reg, such as `rlwinmi`.
781 Normally, with instructions such as `rlwinmi`, the scalar v3.0B ISA would
782 not have sufficient bit fields to allow an alternative destination.
783 With SV however this becomes possible. Therefore, the fact that the
784 dest is implicitly also a src should not mislead: due to the *prefix*
785 they are different SV regs.
787 * `rlwimi RA, RS, ...`
788 * Rsrc1_EXTRA3 applies to RS as the first src
789 * Rsrc2_EXTRA3 applies to RA as the secomd src
790 * Rdest_EXTRA3 applies to RA to create an **independent** dest.
792 With the addition of the EXTRA bits, the three registers
793 each may be *independently* made vector or scalar, and be independently
794 augmented to 7 bits in length.
798 | Field Name | Field bits | Description |
799 |------------|------------|----------------------------|
800 | Rdest_EXTRA3 | `10:12` | extends Rdest |
801 | Rsrc1_EXTRA3 | `13:15` | extends Rsrc1 |
802 | MASK_SRC | `16:18` | Execution Mask for Source |
804 `RM-2P-2S` is for `stw` etc. and is Rsrc1 Rsrc2.
808 single-predicate, three registers (2 read, 1 write)
810 | Field Name | Field bits | Description |
811 |------------|------------|----------------------------|
812 | Rdest_EXTRA3 | `10:12` | extends Rdest |
813 | Rsrc1_EXTRA3 | `13:15` | extends Rsrc1 |
814 | Rsrc2_EXTRA3 | `16:18` | extends Rsrc2 |
816 ### RM-2P-2S1D/1S2D/3S
818 The primary purpose for this encoding is for Twin Predication on LOAD
819 and STORE operations. see [[sv/ldst]] for detailed anslysis.
823 | Field Name | Field bits | Description |
824 |------------|------------|----------------------------|
825 | Rdest_EXTRA2 | `10:11` | extends Rdest (R\*\_EXTRA2 Encoding) |
826 | Rsrc1_EXTRA2 | `12:13` | extends Rsrc1 (R\*\_EXTRA2 Encoding) |
827 | Rsrc2_EXTRA2 | `14:15` | extends Rsrc2 (R\*\_EXTRA2 Encoding) |
828 | MASK_SRC | `16:18` | Execution Mask for Source |
832 For RM-2P-1S2D the EXTRA2 dest and src names are switched (Rsrc_EXTRA2
833 is in bits 10:11, Rdest1_EXTRA2 in 12:13)
835 | Field Name | Field bits | Description |
836 |------------|------------|----------------------------|
837 | Rsrc2_EXTRA2 | `10:11` | extends Rsrc2 (R\*\_EXTRA2 Encoding) |
838 | Rsrc1_EXTRA2 | `12:13` | extends Rsrc1 (R\*\_EXTRA2 Encoding) |
839 | Rdest_EXTRA2 | `14:15` | extends Rdest (R\*\_EXTRA2 Encoding) |
840 | MASK_SRC | `16:18` | Execution Mask for Source |
844 Also that for RM-2P-3S (to cover `stdx` etc.) the names are switched to 3 src:
845 Rsrc1_EXTRA2, Rsrc2_EXTRA2, Rsrc3_EXTRA2.
847 | Field Name | Field bits | Description |
848 |------------|------------|----------------------------|
849 | Rsrc1_EXTRA2 | `10:11` | extends Rsrc1 (R\*\_EXTRA2 Encoding) |
850 | Rsrc2_EXTRA2 | `12:13` | extends Rsrc2 (R\*\_EXTRA2 Encoding) |
851 | Rsrc3_EXTRA2 | `14:15` | extends Rsrc3 (R\*\_EXTRA2 Encoding) |
852 | MASK_SRC | `16:18` | Execution Mask for Source |
854 Note also that LD with update indexed, which takes 2 src and
855 creates 2 dest registers (e.g. `lhaux RT,RA,RB`), does not have room
856 for 4 registers and also Twin Predication. Therefore these are treated as
857 RM-2P-2S1D and the src spec for RA is also used for the same RA as a dest.
859 Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance
860 or increased latency in some implementations due to lane-crossing.
864 EXTRA is the means by which two things are achieved:
866 1. Registers are marked as either Vector *or Scalar*
867 2. Register field numbers (limited typically to 5 bit)
868 are extended in range, both for Scalar and Vector.
870 The register files are therefore extended:
872 * INT (GPR) is extended from r0-31 to r0-127
873 * FP (FPR) is extended from fp0-32 to fp0-fp127
874 * CR Fields are extended from CR0-7 to CR0-127
876 However due to pressure in `RM.EXTRA` not all these registers
877 are accessible by all instructions, particularly those with
878 a large number of operands (`madd`, `isel`).
880 In the following tables register numbers are constructed from the
881 standard v3.0B / v3.1B 32 bit register field (RA, FRA) and the EXTRA2 or
882 EXTRA3 field from the SV Prefix, determined by the specific RM-xx-yyyy
883 designation for a given instruction. The prefixing is arranged so that
884 interoperability between prefixing and nonprefixing of scalar registers
885 is direct and convenient (when the EXTRA field is all zeros).
887 A pseudocode algorithm explains the relationship, for INT/FP (see
888 SVP64 appendix for CRs)
894 spec = EXTRA2 << 1 # same as EXTRA3, shifted
896 return (RA << 2) | spec[1:2]
898 return (spec[1:2] << 5) | RA
901 Future versions may extend to 256 by shifting Vector numbering up.
902 Scalar will not be altered.
904 Note that in some cases the range of starting points for Vectors
909 If EXTRA3 is zero, maps to "scalar identity" (scalar Power ISA field
912 Fields are as follows:
915 * Mode: register is tagged as scalar or vector
916 * Range/Inc: the range of registers accessible from this EXTRA
917 encoding, and the "increment" (accessibility). "/4" means
918 that this EXTRA encoding may only give access (starting point)
920 * MSB..LSB: the bit field showing how the register opcode field
921 combines with EXTRA to give (extend) the register number (GPR)
923 | Value | Mode | Range/Inc | 6..0 |
924 |-----------|-------|---------------|---------------------|
925 | 000 | Scalar | `r0-r31`/1 | `0b00 RA` |
926 | 001 | Scalar | `r32-r63`/1 | `0b01 RA` |
927 | 010 | Scalar | `r64-r95`/1 | `0b10 RA` |
928 | 011 | Scalar | `r96-r127`/1 | `0b11 RA` |
929 | 100 | Vector | `r0-r124`/4 | `RA 0b00` |
930 | 101 | Vector | `r1-r125`/4 | `RA 0b01` |
931 | 110 | Vector | `r2-r126`/4 | `RA 0b10` |
932 | 111 | Vector | `r3-r127`/4 | `RA 0b11` |
936 If EXTRA2 is zero will map to
937 "scalar identity behaviour" i.e Scalar Power ISA register naming:
939 | Value | Mode | Range/inc | 6..0 |
940 |----------|-------|---------------|-----------|
941 | 00 | Scalar | `r0-r31`/1 | `0b00 RA` |
942 | 01 | Scalar | `r32-r63`/1 | `0b01 RA` |
943 | 10 | Vector | `r0-r124`/4 | `RA 0b00` |
944 | 11 | Vector | `r2-r126`/4 | `RA 0b10` |
946 **Note that unlike in EXTRA3, in EXTRA2**:
948 * the GPR Vectors may only start from
949 `r0, r2, r4, r6, r8` and likewise FPR Vectors.
950 * the GPR Scalars may only go from `r0, r1, r2.. r63` and likewise FPR Scalars.
952 as there is insufficient bits to cover the full range.
956 CR Field encoding is essentially the same but made more complex due to CRs
957 being bit-based, because the application of SVP64 element-numbering applies
958 to the CR *Field* numbering not the CR register *bit* numbering.
959 Note that Vectors may only start from `CR0, CR4, CR8, CR12, CR16, CR20`...
960 and Scalars may only go from `CR0, CR1, ... CR31`
962 Encoding shown MSB down to LSB
964 For a 5-bit operand (BA, BB, BT):
966 | Value | Mode | Range/Inc | 8..5 | 4..2 | 1..0 |
967 |-------|------|---------------|-----------| --------|---------|
968 | 000 | Scalar | `CR0-CR7`/1 | 0b0000 | BA[0:2] | BA[3:4] |
969 | 001 | Scalar | `CR8-CR15`/1 | 0b0001 | BA[0:2] | BA[3:4] |
970 | 010 | Scalar | `CR16-CR23`/1 | 0b0010 | BA[0:2] | BA[3:4] |
971 | 011 | Scalar | `CR24-CR31`/1 | 0b0011 | BA[0:2] | BA[3:4] |
972 | 100 | Vector | `CR0-CR112`/16 | BA[0:2] 0 | 0b000 | BA[3:4] |
973 | 101 | Vector | `CR4-CR116`/16 | BA[0:2] 0 | 0b100 | BA[3:4] |
974 | 110 | Vector | `CR8-CR120`/16 | BA[0:2] 1 | 0b000 | BA[3:4] |
975 | 111 | Vector | `CR12-CR124`/16 | BA[0:2] 1 | 0b100 | BA[3:4] |
977 For a 3-bit operand (e.g. BFA):
979 | Value | Mode | Range/Inc | 6..3 | 2..0 |
980 |-------|------|---------------|-----------| --------|
981 | 000 | Scalar | `CR0-CR7`/1 | 0b0000 | BFA |
982 | 001 | Scalar | `CR8-CR15`/1 | 0b0001 | BFA |
983 | 010 | Scalar | `CR16-CR23`/1 | 0b0010 | BFA |
984 | 011 | Scalar | `CR24-CR31`/1 | 0b0011 | BFA |
985 | 100 | Vector | `CR0-CR112`/16 | BFA 0 | 0b000 |
986 | 101 | Vector | `CR4-CR116`/16 | BFA 0 | 0b100 |
987 | 110 | Vector | `CR8-CR120`/16 | BFA 1 | 0b000 |
988 | 111 | Vector | `CR12-CR124`/16 | BFA 1 | 0b100 |
992 CR encoding is essentially the same but made more complex due to CRs
993 being bit-based, because the application of SVP64 element-numbering applies
994 to the CR *Field* numbering not the CR register *bit* numbering.
995 See separate section for explanation and pseudocode.
996 Note that Vectors may only start from CR0, CR8, CR16, CR24, CR32...
998 Encoding shown MSB down to LSB
1000 For a 5-bit operand (BA, BB, BC):
1002 | Value | Mode | Range/Inc | 8..5 | 4..2 | 1..0 |
1003 |-------|--------|----------------|---------|---------|---------|
1004 | 00 | Scalar | `CR0-CR7`/1 | 0b0000 | BA[0:2] | BA[3:4] |
1005 | 01 | Scalar | `CR8-CR15`/1 | 0b0001 | BA[0:2] | BA[3:4] |
1006 | 10 | Vector | `CR0-CR112`/16 | BA[0:2] 0 | 0b000 | BA[3:4] |
1007 | 11 | Vector | `CR8-CR120`/16 | BA[0:2] 1 | 0b000 | BA[3:4] |
1009 For a 3-bit operand (e.g. BFA):
1011 | Value | Mode | Range/Inc | 6..3 | 2..0 |
1012 |-------|------|---------------|-----------| --------|
1013 | 00 | Scalar | `CR0-CR7`/1 | 0b0000 | BFA |
1014 | 01 | Scalar | `CR8-CR15`/1 | 0b0001 | BFA |
1015 | 10 | Vector | `CR0-CR112`/16 | BFA 0 | 0b000 |
1016 | 11 | Vector | `CR8-CR120`/16 | BFA 1 | 0b000 |
1023 # Normal SVP64 Modes, for Arithmetic and Logical Operations
1025 Normal SVP64 Mode covers Arithmetic and Logical operations
1026 to provide suitable additional behaviour. The Mode
1027 field is bits 19-23 of the [[svp64]] RM Field.
1031 Mode is an augmentation of SV behaviour, providing additional
1032 functionality. Some of these alterations are element-based (saturation),
1033 others involve post-analysis (predicate result) and others are
1034 Vector-based (mapreduce, fail-on-first).
1036 [[sv/ldst]], [[sv/cr_ops]] and [[sv/branches]] are covered separately:
1037 the following Modes apply to Arithmetic and Logical SVP64 operations:
1039 * **simple** mode is straight vectorisation. no augmentations: the
1040 vector comprises an array of independently created results.
1041 * **ffirst** or data-dependent fail-on-first: see separate section.
1042 the vector may be truncated depending on certain criteria.
1043 *VL is altered as a result*.
1044 * **sat mode** or saturation: clamps each element result to a min/max
1045 rather than overflows / wraps. allows signed and unsigned clamping
1046 for both INT and FP.
1047 * **reduce mode**. if used correctly, a mapreduce (or a prefix sum)
1048 is performed. see [[svp64/appendix]].
1049 note that there are comprehensive caveats when using this mode.
1050 * **pred-result** will test the result (CR testing selects a bit of CR
1051 and inverts it, just like branch conditional testing) and if the
1052 test fails it is as if the *destination* predicate bit was zero even
1053 before starting the operation. When Rc=1 the CR element however is
1054 still stored in the CR regfile, even if the test failed. See appendix
1057 Note that ffirst and reduce modes are not anticipated to be
1058 high-performance in some implementations. ffirst due to interactions
1059 with VL, and reduce due to it requiring additional operations to produce
1060 a result. simple, saturate and pred-result are however inter-element
1061 independent and may easily be parallelised to give high performance,
1062 regardless of the value of VL.
1064 The Mode table for Arithmetic and Logical operations is laid out as
1067 | 0-1 | 2 | 3 4 | description |
1068 | --- | --- |---------|-------------------------- |
1069 | 00 | 0 | dz sz | simple mode |
1070 | 00 | 1 | 0 RG | scalar reduce mode (mapreduce) |
1071 | 00 | 1 | 1 / | reserved |
1072 | 01 | inv | CR-bit | Rc=1: ffirst CR sel |
1073 | 01 | inv | VLi RC1 | Rc=0: ffirst z/nonz |
1074 | 10 | N | dz sz | sat mode: N=0/1 u/s |
1075 | 11 | inv | CR-bit | Rc=1: pred-result CR sel |
1076 | 11 | inv | zz RC1 | Rc=0: pred-result z/nonz |
1080 * **sz / dz** if predication is enabled will put zeros into the dest
1081 (or as src in the case of twin pred) when the predicate bit is zero.
1082 otherwise the element is ignored or skipped, depending on context.
1083 * **zz**: both sz and dz are set equal to this flag
1084 * **inv CR bit** just as in branches (BO) these bits allow testing of
1085 a CR bit and whether it is set (inv=0) or unset (inv=1)
1086 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
1087 than the normal 0..VL-1
1088 * **N** sets signed/unsigned saturation.
1089 * **RC1** as if Rc=1, enables access to `VLi`.
1090 * **VLi** VL inclusive: in fail-first mode, the truncation of
1091 VL *includes* the current element at the failure point rather
1092 than excludes it from the count.
1094 For LD/ST Modes, see [[sv/ldst]]. For Condition Registers see
1095 [[sv/cr_ops]]. For Branch modes, see [[sv/branches]].
1097 ## Rounding, clamp and saturate
1099 To help ensure for example that audio quality is not compromised by
1100 overflow, "saturation" is provided, as well as a way to detect when
1101 saturation occurred if desired (Rc=1). When Rc=1 there will be a *vector*
1102 of CRs, one CR per element in the result (Note: this is different from
1103 VSX which has a single CR per block).
1105 When N=0 the result is saturated to within the maximum range of an
1106 unsigned value. For integer ops this will be 0 to 2^elwidth-1. Similar
1107 logic applies to FP operations, with the result being saturated to
1108 maximum rather than returning INF, and the minimum to +0.0
1110 When N=1 the same occurs except that the result is saturated to the min
1111 or max of a signed result, and for FP to the min and max value rather
1112 than returning +/- INF.
1114 When Rc=1, the CR "overflow" bit is set on the CR associated with
1115 the element, to indicate whether saturation occurred. Note that
1116 due to the hugely detrimental effect it has on parallel processing,
1117 XER.SO is **ignored** completely and is **not** brought into play here.
1118 The CR overflow bit is therefore simply set to zero if saturation did
1119 not occur, and to one if it did. This behaviour (ignoring XER.SO) is
1120 actually optional in the SFFS Compliancy Subset: for SVP64 it is made
1121 mandatory *but only on Vectorised instructions*.
1123 Note also that saturate on operations that set OE=1 must raise an Illegal
1124 Instruction due to the conflicting use of the CR.so bit for storing
1125 if saturation occurred. Vectorised Integer Operations that produce a
1126 Carry-Out (CA, CA32): these two bits will be `UNDEFINED` if saturation
1129 Note that the operation takes place at the maximum bitwidth (max of
1130 src and dest elwidth) and that truncation occurs to the range of the
1133 *Programmer's Note: Post-analysis of the Vector of CRs to find out if any
1134 given element hit saturation may be done using a mapreduced CR op (cror),
1135 or by using the new crrweird instruction with Rc=1, which will transfer
1136 the required CR bits to a scalar integer and update CR0, which will allow
1137 testing the scalar integer for nonzero. see [[sv/cr_int_predication]].
1138 Alternatively, a Data-Dependent Fail-First may be used to truncate the
1139 Vector Length to non-saturated elements, greatly increasing the productivity
1140 of parallelised inner hot-loops.*
1144 Reduction in SVP64 is similar in essence to other Vector Processing ISAs,
1145 but leverages the underlying scalar Base v3.0B operations. Thus it is
1146 more a convention that the programmer may utilise to give the appearance
1147 and effect of a Horizontal Vector Reduction. Due to the unusual decoupling
1148 it is also possible to perform prefix-sum (Fibonacci Series) in certain
1149 circumstances. Details are in the SVP64 appendix
1151 Reduce Mode should not be confused with Parallel Reduction [[sv/remap]].
1152 As explained in the [[sv/appendix]] Reduce Mode switches off the check
1153 which would normally stop looping if the result register is scalar.
1154 Thus, the result scalar register, if also used as a source scalar,
1155 may be used to perform sequential accumulation. This *deliberately*
1156 sets up a chain of Register Hazard Dependencies, whereas Parallel Reduce
1157 [[sv/remap]] deliberately issues a Tree-Schedule of operations that may
1160 ## Data-dependent Fail-on-first
1162 Data-dependent fail-on-first is very different from LD/ST Fail-First
1163 (also known as Fault-First) and is actually CR-field-driven.
1164 Vector elements are required to appear
1165 to be executed in sequential Program Order. When REMAP is not active,
1166 element 0 would be the first.
1168 Data-driven (CR-driven) fail-on-first activates when Rc=1 or other
1169 CR-creating operation produces a result (including cmp). Similar to
1170 branch, an analysis of the CR is performed and if the test fails, the
1171 vector operation terminates and discards all element operations **at and
1172 above the current one**, and VL is truncated to either the *previous*
1173 element or the current one, depending on whether VLi (VL "inclusive")
1174 is clear or set, respectively.
1176 Thus the new VL comprises a contiguous vector of results, all of which
1177 pass the testing criteria (equal to zero, less than zero etc as defined
1178 by the CR-bit test).
1180 *Note: when VLi is clear, the behaviour at first seems counter-intuitive.
1181 A result is calculated but if the test fails it is prohibited from being
1182 actually written. This becomes intuitive again when it is remembered
1183 that the length that VL is set to is the number of *written* elements, and
1184 only when VLI is set will the current element be included in that count.*
1186 The CR-based data-driven fail-on-first is "new" and not found in ARM SVE
1187 or RVV. At the same time it is "old" because it is almost identical to
1188 a generalised form of Z80's `CPIR` instruction. It is extremely useful
1189 for reducing instruction count, however requires speculative execution
1190 involving modifications of VL to get high performance implementations.
1191 An additional mode (RC1=1) effectively turns what would otherwise be an
1192 arithmetic operation into a type of `cmp`. The CR is stored (and the
1193 CR.eq bit tested against the `inv` field). If the CR.eq bit is equal to
1194 `inv` then the Vector is truncated and the loop ends.
1196 VLi is only available as an option when `Rc=0` (or for instructions
1197 which do not have Rc). When set, the current element is always also
1198 included in the count (the new length that VL will be set to). This may
1199 be useful in combination with "inv" to truncate the Vector to *exclude*
1200 elements that fail a test, or, in the case of implementations of strncpy,
1201 to include the terminating zero.
1203 In CR-based data-driven fail-on-first there is only the option to select
1204 and test one bit of each CR (just as with branch BO). For more complex
1205 tests this may be insufficient. If that is the case, a vectorised crop
1206 such as crand, cror or [[sv/cr_int_predication]] crweirder may be used,
1207 and ffirst applied to the crop instead of to the arithmetic vector. Note
1208 that crops are covered by the [[sv/cr_ops]] Mode format.
1210 Use of Fail-on-first with Vertical-First Mode is not prohibited but is
1211 not really recommended. The effect of truncating VL
1212 may have unintended and unexpected consequences on subsequent instructions.
1213 VLi set will be fine: it is when VLi is clear that problems may be faced.
1215 *Programmer's note: `VLi` is only accessible in normal operations which in
1216 turn limits the CR field bit-testing to only `EQ/NE`. [[sv/cr_ops]] are
1217 not so limited. Thus it is possible to use for example `sv.cror/ff=gt/vli
1218 *0,*0,*0`, which is not a `nop` because it allows Fail-First Mode to
1219 perform a test and truncate VL.*
1221 *Hardware implementor's note: effective Sequential Program Order must
1222 be preserved. Speculative Execution is perfectly permitted as long as
1223 the speculative elements are held back from writing to register files
1224 (kept in Resevation Stations), until such time as the relevant CR Field
1225 bit(s) has been analysed. All Speculative elements sequentially beyond
1226 the test-failure point **MUST** be cancelled. This is no different from
1227 standard Out-of-Order Execution and the modification effort to efficiently
1228 support Data-Dependent Fail-First within a pre-existing Multi-Issue
1229 Out-of-Order Engine is anticipated to be minimal. In-Order systems on
1230 the other hand are expected, unavoidably, to be low-performance*.
1232 Two extremely important aspects of ffirst are:
1234 * LDST ffirst may never set VL equal to zero. This because on the first
1235 element an exception must be raised "as normal".
1236 * CR-based data-dependent ffirst on the other hand **can** set VL equal
1237 to zero. This is the only means in the entirety of SV that VL may be set
1238 to zero (with the exception of via the SV.STATE SPR). When VL is set
1239 zero due to the first element failing the CR bit-test, all subsequent
1240 vectorised operations are effectively `nops` which is
1241 *precisely the desired and intended behaviour*.
1243 The second crucial aspect, compared to LDST Ffirst:
1245 * LD/ST Failfirst may (beyond the initial first element
1246 conditions) truncate VL for any architecturally suitable reason. Beyond
1247 the first element LD/ST Failfirst is arbitrarily speculative and 100%
1249 * CR-based data-dependent first on the other hand MUST NOT truncate VL
1250 arbitrarily to a length decided by the hardware: VL MUST only be
1251 truncated based explicitly on whether a test fails. This because it is
1252 a precise Deterministic test on which algorithms can and will will rely.
1254 **Floating-point Exceptions**
1256 When Floating-point exceptions are enabled VL must be truncated at
1257 the point where the Exception appears not to have occurred. If `VLi`
1258 is set then VL must include the faulting element, and thus the faulting
1259 element will always raise its exception. If however `VLi` is clear then
1260 VL **excludes** the faulting element and thus the exception will **never**
1263 Although very strongly discouraged the Exception Mode that permits
1264 Floating Point Exception notification to arrive too late to unwind
1265 is permitted (under protest, due it violating the otherwise 100%
1266 Deterministic nature of Data-dependent Fail-first) and is `UNDEFINED`
1269 **Use of lax FP Exception Notification Mode could result in parallel
1270 computations proceeding with invalid results that have to be explicitly
1271 detected, whereas with the strict FP Execption Mode enabled, FFirst
1272 truncates VL, allows subsequent parallel computation to avoid the
1273 exceptions entirely**
1275 ## Data-dependent fail-first on CR operations (crand etc)
1277 Operations that actually produce or alter CR Field as a result have
1278 their own SVP64 Mode, described in [[sv/cr_ops]].
1282 This mode merges common CR testing with predication, saving on instruction
1283 count. Below is the pseudocode excluding predicate zeroing and elwidth
1284 overrides. Note that the pseudocode for SVP64 CR-ops is slightly different.
1288 # predication test, skip all masked out elements.
1289 if predicate_masked_out(i):
1291 result = op(iregs[RA+i], iregs[RB+i])
1292 CRnew = analyse(result) # calculates eq/lt/gt
1293 # Rc=1 always stores the CR field
1295 CR.field[offs+i] = CRnew
1296 # now test CR, similar to branch
1297 if RC1 or CR.field[BO[0:1]] != BO[2]:
1298 continue # test failed: cancel store
1299 # result optionally stored but CR always is
1300 iregs[RT+i] = result
1303 The reason for allowing the CR element to be stored is so that
1304 post-analysis of the CR Vector may be carried out. For example:
1305 Saturation may have occurred (and been prevented from updating, by the
1306 test) but it is desirable to know *which* elements fail saturation.
1308 Note that RC1 Mode basically turns all operations into `cmp`. The
1309 calculation is performed but it is only the CR that is written. The
1310 element result is *always* discarded, never written (just like `cmp`).
1312 Note that predication is still respected: predicate zeroing is slightly
1313 different: elements that fail the CR test *or* are masked out are zero'd.
1323 All Vector ISAs dating back fifty years have extensive and comprehensive
1324 Load and Store operations that go far beyond the capabilities of Scalar
1325 RISC and most CISC processors, yet at their heart on an individual element
1326 basis may be found to be no different from RISC Scalar equivalents.
1328 The resource savings from Vector LD/ST are significant and stem
1329 from the fact that one single instruction can trigger a dozen (or in
1330 some microarchitectures such as Cray or NEC SX Aurora) hundreds of
1331 element-level Memory accesses.
1333 Additionally, and simply: if the Arithmetic side of an ISA supports
1334 Vector Operations, then in order to keep the ALUs 100% occupied the
1335 Memory infrastructure (and the ISA itself) correspondingly needs Vector
1336 Memory Operations as well.
1338 Vectorised Load and Store also presents an extra dimension (literally)
1339 which creates scenarios unique to Vector applications, that a Scalar (and
1340 even a SIMD) ISA simply never encounters. SVP64 endeavours to add the
1341 modes typically found in *all* Scalable Vector ISAs, without changing the
1342 behaviour of the underlying Base (Scalar) v3.0B operations in any way.
1343 (The sole apparent exception is Post-Increment Mode on LD/ST-update
1348 Vectorisation of Load and Store requires creation, from scalar operations,
1349 a number of different modes:
1351 * **fixed aka "unit" stride** - contiguous sequence with no gaps
1352 * **element strided** - sequential but regularly offset, with gaps
1353 * **vector indexed** - vector of base addresses and vector of offsets
1354 * **Speculative fail-first** - where it makes sense to do so
1355 * **Structure Packing** - covered in SV by [[sv/remap]] and Pack/Unpack Mode.
1357 *Despite being constructed from Scalar LD/ST none of these Modes exist
1358 or make sense in any Scalar ISA. They **only** exist in Vector ISAs*
1360 Also included in SVP64 LD/ST is both signed and unsigned Saturation,
1361 as well as Element-width overrides and Twin-Predication.
1363 Note also that Indexed [[sv/remap]] mode may be applied to both v3.0
1364 LD/ST Immediate instructions *and* v3.0 LD/ST Indexed instructions.
1365 LD/ST-Indexed should not be conflated with Indexed REMAP mode:
1366 clarification is provided below.
1368 **Determining the LD/ST Modes**
1370 A minor complication (caused by the retro-fitting of modern Vector
1371 features to a Scalar ISA) is that certain features do not exactly make
1372 sense or are considered a security risk. Fail-first on Vector Indexed
1373 would allow attackers to probe large numbers of pages from userspace,
1374 where strided fail-first (by creating contiguous sequential LDs) does not.
1376 In addition, reduce mode makes no sense. Realistically we need an
1377 alternative table definition for [[sv/svp64]] `RM.MODE`. The following
1381 * predicate-result (mostly for cache-inhibited LD/ST)
1382 * simple (no augmentation)
1383 * fail-first (where Vector Indexed is banned)
1384 * Signed Effective Address computation (Vector Indexed only)
1386 More than that however it is necessary to fit the usual Vector ISA
1387 capabilities onto both Power ISA LD/ST with immediate and to LD/ST
1388 Indexed. They present subtly different Mode tables, which, due to lack
1389 of space, have the following quirks:
1391 * LD/ST Immediate has no individual control over src/dest zeroing,
1392 whereas LD/ST Indexed does.
1393 * LD/ST Indexed has limited zeroing on pred-result, LD/ST Immediate has
1394 *no* option to select zeroing on pred-result.
1396 ## Format and fields
1398 Fields used in tables below:
1400 * **sz / dz** if predication is enabled will put zeros into the dest
1401 (or as src in the case of twin pred) when the predicate bit is zero.
1402 otherwise the element is ignored or skipped, depending on context.
1403 * **zz**: both sz and dz are set equal to this flag.
1404 * **inv CR bit** just as in branches (BO) these bits allow testing of
1405 a CR bit and whether it is set (inv=0) or unset (inv=1)
1406 * **N** sets signed/unsigned saturation.
1407 * **RC1** as if Rc=1, stores CRs *but not the result*
1408 * **SEA** - Signed Effective Address, if enabled performs sign-extension on
1409 registers that have been reduced due to elwidth overrides
1410 * **PI** - post-increment mode (applies to LD/ST with update only).
1411 the Effective Address utilised is always just RA, i.e. the computation of
1412 EA is stored in RA **after** it is actually used.
1413 * **LF** - Load/Store Fail or Fault First: for any reason Load or Store Vectors
1414 may be truncated to (at least) one element, and VL altered to indicate such.
1418 The table for [[sv/svp64]] for `immed(RA)` which is `RM.MODE`
1419 (bits 19:23 of `RM`) is:
1421 | 0-1 | 2 | 3 4 | description |
1422 | --- | --- |---------|--------------------------- |
1423 | 00 | 0 | zz els | simple mode |
1424 | 00 | 1 | PI LF | post-increment and Fault-First |
1425 | 01 | inv | CR-bit | Rc=1: ffirst CR sel |
1426 | 01 | inv | els RC1 | Rc=0: ffirst z/nonz |
1427 | 10 | N | zz els | sat mode: N=0/1 u/s |
1428 | 11 | inv | CR-bit | Rc=1: pred-result CR sel |
1429 | 11 | inv | els RC1 | Rc=0: pred-result z/nonz |
1431 The `els` bit is only relevant when `RA.isvec` is clear: this indicates
1432 whether stride is unit or element:
1436 svctx.ldstmode = indexed
1438 svctx.ldstmode = unitstride
1439 elif immediate != 0:
1440 svctx.ldstmode = elementstride
1443 An immediate of zero is a safety-valve to allow `LD-VSPLAT`: in effect
1444 the multiplication of the immediate-offset by zero results in reading from
1445 the exact same memory location, *even with a Vector register*. (Normally
1446 this type of behaviour is reserved for the mapreduce modes)
1448 For `LD-VSPLAT`, on non-cache-inhibited Loads, the read can occur just
1449 the once and be copied, rather than hitting the Data Cache multiple
1450 times with the same memory read at the same location. The benefit of
1451 Cache-inhibited LD-splats is that it allows for memory-mapped peripherals
1452 to have multiple data values read in quick succession and stored in
1453 sequentially numbered registers (but, see Note below).
1455 For non-cache-inhibited ST from a vector source onto a scalar destination:
1456 with the Vector loop effectively creating multiple memory writes to
1457 the same location, we can deduce that the last of these will be the
1458 "successful" one. Thus, implementations are free and clear to optimise
1459 out the overwriting STs, leaving just the last one as the "winner".
1460 Bear in mind that predicate masks will skip some elements (in source
1461 non-zeroing mode). Cache-inhibited ST operations on the other hand
1462 **MUST** write out a Vector source multiple successive times to the exact
1463 same Scalar destination. Just like Cache-inhibited LDs, multiple values
1464 may be written out in quick succession to a memory-mapped peripheral
1465 from sequentially-numbered registers.
1467 Note that any memory location may be Cache-inhibited
1468 (Power ISA v3.1, Book III, 1.6.1, p1033)
1470 *Programmer's Note: an immediate also with a Scalar source as a "VSPLAT"
1471 mode is simply not possible: there are not enough Mode bits. One single
1472 Scalar Load operation may be used instead, followed by any arithmetic
1473 operation (including a simple mv) in "Splat" mode.*
1477 The modes for `RA+RB` indexed version are slightly different
1478 but are the same `RM.MODE` bits (19:23 of `RM`):
1480 | 0-1 | 2 | 3 4 | description |
1481 | --- | --- |---------|-------------------------- |
1482 | 00 | SEA | dz sz | simple mode |
1483 | 01 | SEA | dz sz | Strided (scalar only source) |
1484 | 10 | N | dz sz | sat mode: N=0/1 u/s |
1485 | 11 | inv | CR-bit | Rc=1: pred-result CR sel |
1486 | 11 | inv | zz RC1 | Rc=0: pred-result z/nonz |
1488 Vector Indexed Strided Mode is qualified as follows:
1490 if mode = 0b01 and !RA.isvec and !RB.isvec:
1491 svctx.ldstmode = elementstride
1493 A summary of the effect of Vectorisation of src or dest:
1496 imm(RA) RT.v RA.v no stride allowed
1497 imm(RA) RT.s RA.v no stride allowed
1498 imm(RA) RT.v RA.s stride-select allowed
1499 imm(RA) RT.s RA.s not vectorised
1500 RA,RB RT.v {RA|RB}.v Standard Indexed
1501 RA,RB RT.s {RA|RB}.v Indexed but single LD (no VSPLAT)
1502 RA,RB RT.v {RA&RB}.s VSPLAT possible. stride selectable
1503 RA,RB RT.s {RA&RB}.s not vectorised (scalar identity)
1506 Signed Effective Address computation is only relevant for Vector Indexed
1507 Mode, when elwidth overrides are applied. The source override applies to
1508 RB, and before adding to RA in order to calculate the Effective Address,
1509 if SEA is set RB is sign-extended from elwidth bits to the full 64 bits.
1510 For other Modes (ffirst, saturate), all EA computation with elwidth
1511 overrides is unsigned.
1513 Note that cache-inhibited LD/ST when VSPLAT is activated will perform
1514 **multiple** LD/ST operations, sequentially. Even with scalar src
1515 a Cache-inhibited LD will read the same memory location *multiple
1516 times*, storing the result in successive Vector destination registers.
1517 This because the cache-inhibit instructions are typically used to read
1518 and write memory-mapped peripherals. If a genuine cache-inhibited
1519 LD-VSPLAT is required then a single *scalar* cache-inhibited LD should
1520 be performed, followed by a VSPLAT-augmented mv, copying the one *scalar*
1521 value into multiple register destinations.
1523 Note also that cache-inhibited VSPLAT with Predicate-result is possible.
1524 This allows for example to issue a massive batch of memory-mapped
1525 peripheral reads, stopping at the first NULL-terminated character and
1526 truncating VL to that point. No branch is needed to issue that large
1527 burst of LDs, which may be valuable in Embedded scenarios.
1529 ## Vectorisation of Scalar Power ISA v3.0B
1531 Scalar Power ISA Load/Store operations may be seen from their
1532 pseudocode to be of the form:
1540 and for immediate variants:
1548 Thus in the first example, the source registers may each be independently
1549 marked as scalar or vector, and likewise the destination; in the second
1550 example only the one source and one dest may be marked as scalar or
1553 Thus we can see that Vector Indexed may be covered, and, as demonstrated
1554 with the pseudocode below, the immediate can be used to give unit
1555 stride or element stride. With there being no way to tell which from
1556 the Power v3.0B Scalar opcode alone, the choice is provided instead by
1560 # LD not VLD! format - ldop RT, immed(RA)
1561 # op_width: lb=1, lh=2, lw=4, ld=8
1562 op_load(RT, RA, op_width, immed, svctx, RAupdate):
1563 ps = get_pred_val(FALSE, RA); # predication on src
1564 pd = get_pred_val(FALSE, RT); # ... AND on dest
1565 for (i=0, j=0, u=0; i < VL && j < VL;):
1566 # skip nonpredicates elements
1567 if (RA.isvec) while (!(ps & 1<<i)) i++;
1568 if (RAupdate.isvec) while (!(ps & 1<<u)) u++;
1569 if (RT.isvec) while (!(pd & 1<<j)) j++;
1571 offs = 0; # added afterwards
1572 if RA.isvec: srcbase = ireg[RA+i]
1573 else srcbase = ireg[RA]
1574 elif svctx.ldstmode == elementstride:
1575 # element stride mode
1577 offs = i * immed # j*immed for a ST
1578 elif svctx.ldstmode == unitstride:
1581 offs = immed + (i * op_width) # j*op_width for ST
1583 # quirky Vector indexed mode but with an immediate
1584 srcbase = ireg[RA+i]
1587 # standard scalar mode (but predicated)
1588 # no stride multiplier means VSPLAT mode
1595 ireg[RT+j] <= MEM[EA];
1596 # check post-increment of EA
1597 if postinc: EA = srcbase + immed;
1599 if RAupdate: ireg[RAupdate+u] = EA;
1601 break # destination scalar, end now
1603 if (RAupdate.isvec) u++;
1610 # format: ldop RT, RA, RB
1611 function op_ldx(RT, RA, RB, RAupdate=False) # LD not VLD!
1612 ps = get_pred_val(FALSE, RA); # predication on src
1613 pd = get_pred_val(FALSE, RT); # ... AND on dest
1614 for (i=0, j=0, k=0, u=0; i < VL && j < VL && k < VL):
1615 # skip nonpredicated RA, RB and RT
1616 if (RA.isvec) while (!(ps & 1<<i)) i++;
1617 if (RAupdate.isvec) while (!(ps & 1<<u)) u++;
1618 if (RB.isvec) while (!(ps & 1<<k)) k++;
1619 if (RT.isvec) while (!(pd & 1<<j)) j++;
1620 if svctx.ldstmode == elementstride:
1621 EA = ireg[RA] + ireg[RB]*j # register-strided
1623 EA = ireg[RA+i] + ireg[RB+k] # indexed address
1624 if RAupdate: ireg[RAupdate+u] = EA
1625 ireg[RT+j] <= MEM[EA];
1627 break # destination scalar, end immediately
1629 if (RAupdate.isvec) u++;
1634 Note that Element-Strided uses the Destination Step because with both
1635 sources being Scalar as a prerequisite condition of activation of
1636 Element-Stride Mode, the source step (being Scalar) would never advance.
1638 Note in both cases that [[sv/svp64]] allows RA-as-a-dest in "update"
1639 mode (`ldux`) to be effectively a *completely different* register from
1640 RA-as-a-source. This because there is room in svp64 to extend RA-as-src
1641 as well as RA-as-dest, both independently as scalar or vector *and*
1642 independently extending their range.
1644 *Programmer's note: being able to set RA-as-a-source as separate from
1645 RA-as-a-destination as Scalar is **extremely valuable** once it is
1646 remembered that Simple-V element operations must be in Program Order,
1647 especially in loops, for saving on multiple address computations. Care
1648 does have to be taken however that RA-as-src is not overwritten by
1649 RA-as-dest unless intentionally desired, especially in element-strided
1652 ## LD/ST Indexed vs Indexed REMAP
1654 Unfortunately the word "Indexed" is used twice in completely different
1655 contexts, potentially causing confusion.
1657 * There has existed instructions in the Power ISA `ld RT,RA,RB` since
1658 its creation: these are called "LD/ST Indexed" instructions and their
1659 name and meaning is well-established.
1660 * There now exists, in Simple-V, a REMAP mode called "Indexed"
1661 Mode that can be applied to *any* instruction **including those
1662 named LD/ST Indexed**.
1664 Whilst it may be costly in terms of register reads to allow REMAP Indexed
1665 Mode to be applied to any Vectorised LD/ST Indexed operation such as
1666 `sv.ld *RT,RA,*RB`, or even misleadingly labelled as redundant, firstly
1667 the strict application of the RISC Paradigm that Simple-V follows makes
1668 it awkward to consider *preventing* the application of Indexed REMAP to
1669 such operations, and secondly they are not actually the same at all.
1671 Indexed REMAP, as applied to RB in the instruction `sv.ld *RT,RA,*RB`
1672 effectively performs an *in-place* re-ordering of the offsets, RB.
1673 To achieve the same effect without Indexed REMAP would require taking
1674 a *copy* of the Vector of offsets starting at RB, manually explicitly
1675 reordering them, and finally using the copy of re-ordered offsets in a
1676 non-REMAP'ed `sv.ld`. Using non-strided LD as an example, pseudocode
1677 showing what actually occurs, where the pseudocode for `indexed_remap`
1678 may be found in [[sv/remap]]:
1681 # sv.ld *RT,RA,*RB with Index REMAP applied to RB
1684 rb_idx = indexed_remap(i) # remap
1686 rb_idx = i # use the index as-is
1687 EA = GPR(RA) + GPR(RB+rb_idx)
1688 GPR(RT+i) = MEM(EA, 8)
1691 Thus it can be seen that the use of Indexed REMAP saves copying
1692 and manual reordering of the Vector of RB offsets.
1696 LD/ST ffirst treats the first LD/ST in a vector (element 0 if REMAP
1697 is not active) as an ordinary one, with all behaviour with respect to
1698 Interrupts Exceptions Page Faults Memory Management being identical
1699 in every regard to Scalar v3.0 Power ISA LD/ST. However for elements
1700 1 and above, if an exception would occur, then VL is **truncated**
1701 to the previous element: the exception is **not** then raised because
1702 the LD/ST that would otherwise have caused an exception is *required*
1703 to be cancelled. Additionally an implementor may choose to truncate VL
1704 for any arbitrary reason *except for the very first*.
1706 ffirst LD/ST to multiple pages via a Vectorised Index base is
1707 considered a security risk due to the abuse of probing multiple
1708 pages in rapid succession and getting speculative feedback on which
1709 pages would fail. Therefore Vector Indexed LD/ST is prohibited
1710 entirely, and the Mode bit instead used for element-strided LD/ST.
1713 for(i = 0; i < VL; i++)
1714 reg[rt + i] = mem[reg[ra] + i * reg[rb]];
1717 High security implementations where any kind of speculative probing of
1718 memory pages is considered a risk should take advantage of the fact
1719 that implementations may truncate VL at any point, without requiring
1720 software to be rewritten and made non-portable. Such implementations may
1721 choose to *always* set VL=1 which will have the effect of terminating
1722 any speculative probing (and also adversely affect performance), but
1723 will at least not require applications to be rewritten.
1725 Low-performance simpler hardware implementations may also choose (always)
1726 to also set VL=1 as the bare minimum compliant implementation of LD/ST
1727 Fail-First. It is however critically important to remember that the first
1728 element LD/ST **MUST** be treated as an ordinary LD/ST, i.e. **MUST**
1729 raise exceptions exactly like an ordinary LD/ST.
1731 For ffirst LD/STs, VL may be truncated arbitrarily to a nonzero value
1732 for any implementation-specific reason. For example: it is perfectly
1733 reasonable for implementations to alter VL when ffirst LD or ST operations
1734 are initiated on a nonaligned boundary, such that within a loop the
1735 subsequent iteration of that loop begins the following ffirst LD/ST
1736 operations on an aligned boundary such as the beginning of a cache line,
1737 or beginning of a Virtual Memory page. Likewise, to reduce workloads or
1740 Vertical-First Mode is slightly strange in that only one element at a time
1741 is ever executed anyway. Given that programmers may legitimately choose
1742 to alter srcstep and dststep in non-sequential order as part of explicit
1743 loops, it is neither possible nor safe to make speculative assumptions
1744 about future LD/STs. Therefore, Fail-First LD/ST in Vertical-First is
1745 `UNDEFINED`. This is very different from Arithmetic (Data-dependent)
1746 FFirst where Vertical-First Mode is fully deterministic, not speculative.
1748 ## LOAD/STORE Elwidths <a name="elwidth"></a>
1750 Loads and Stores are almost unique in that the Power Scalar ISA
1751 provides a width for the operation (lb, lh, lw, ld). Only `extsb` and
1752 others like it provide an explicit operation width. There are therefore
1753 *three* widths involved:
1755 * operation width (lb=8, lh=16, lw=32, ld=64)
1756 * src element width override (8/16/32/default)
1757 * destination element width override (8/16/32/default)
1759 Some care is therefore needed to express and make clear the transformations,
1760 which are expressly in this order:
1762 * Calculate the Effective Address from RA at full width
1763 but (on Indexed Load) allow srcwidth overrides on RB
1764 * Load at the operation width (lb/lh/lw/ld) as usual
1765 * byte-reversal as usual
1766 * Non-saturated mode:
1767 - zero-extension or truncation from operation width to dest elwidth
1768 - place result in destination at dest elwidth
1770 - Sign-extension or truncation from operation width to dest width
1771 - signed/unsigned saturation down to dest elwidth
1773 In order to respect Power v3.0B Scalar behaviour the memory side
1774 is treated effectively as completely separate and distinct from SV
1775 augmentation. This is primarily down to quirks surrounding LE/BE and
1778 It is rather unfortunately possible to request an elwidth override on
1779 the memory side which does not mesh with the overridden operation width:
1780 these result in `UNDEFINED` behaviour. The reason is that the effect
1781 of attempting a 64-bit `sv.ld` operation with a source elwidth override
1782 of 8/16/32 would result in overlapping memory requests, particularly
1783 on unit and element strided operations. Thus it is `UNDEFINED` when
1784 the elwidth is smaller than the memory operation width. Examples include
1785 `sv.lw/sw=16/els` which requests (overlapping) 4-byte memory reads offset
1786 from each other at 2-byte intervals. Store likewise is also `UNDEFINED`
1787 where the dest elwidth override is less than the operation width.
1789 Note the following regarding the pseudocode to follow:
1791 * `scalar identity behaviour` SV Context parameter conditions turn this
1792 into a straight absolute fully-compliant Scalar v3.0B LD operation
1793 * `brev` selects whether the operation is the byte-reversed variant (`ldbrx`
1795 * `op_width` specifies the operation width (`lb`, `lh`, `lw`, `ld`) as
1796 a "normal" part of Scalar v3.0B LD
1797 * `imm_offs` specifies the immediate offset `ld r3, imm_offs(r5)`, again
1798 as a "normal" part of Scalar v3.0B LD
1799 * `svctx` specifies the SV Context and includes VL as well as
1800 source and destination elwidth overrides.
1802 Below is the pseudocode for Unit-Strided LD (which includes Vector
1803 capability). Observe in particular that RA, as the base address in both
1804 Immediate and Indexed LD/ST, does not have element-width overriding
1807 Note that predication, predication-zeroing, and other modes except
1808 saturation have all been removed, for clarity and simplicity:
1812 # this covers unit stride mode and a type of vector offset
1813 function op_ld(RT, RA, op_width, imm_offs, svctx)
1814 for (int i = 0, int j = 0; i < svctx.VL && j < svctx.VL):
1815 if not svctx.unit/el-strided:
1816 # strange vector mode, compute 64 bit address which is
1817 # not polymorphic! elwidth hardcoded to 64 here
1818 srcbase = get_polymorphed_reg(RA, 64, i)
1820 # unit / element stride mode, compute 64 bit address
1821 srcbase = get_polymorphed_reg(RA, 64, 0)
1822 # adjust for unit/el-stride
1825 # read the underlying memory
1826 memread <= MEM(srcbase + imm_offs, op_width)
1829 if svpctx.saturation_mode:
1830 # ... saturation adjustment...
1831 memread = clamp(memread, op_width, svctx.dest_elwidth)
1833 # truncate/extend to over-ridden dest width.
1834 memread = adjust_wid(memread, op_width, svctx.dest_elwidth)
1836 # takes care of inserting memory-read (now correctly byteswapped)
1837 # into regfile underlying LE-defined order, into the right place
1838 # within the NEON-like register, respecting destination element
1839 # bitwidth, and the element index (j)
1840 set_polymorphed_reg(RT, svctx.dest_elwidth, j, memread)
1842 # increments both src and dest element indices (no predication here)
1847 Note above that the source elwidth is *not used at all* in LD-immediate.
1849 For LD/Indexed, the key is that in the calculation of the Effective Address,
1850 RA has no elwidth override but RB does. Pseudocode below is simplified
1851 for clarity: predication and all modes except saturation are removed:
1854 # LD not VLD! ld*rx if brev else ld*
1855 function op_ld(RT, RA, RB, op_width, svctx, brev)
1856 for (int i = 0, int j = 0; i < svctx.VL && j < svctx.VL):
1857 if not svctx.el-strided:
1858 # RA not polymorphic! elwidth hardcoded to 64 here
1859 srcbase = get_polymorphed_reg(RA, 64, i)
1861 # element stride mode, again RA not polymorphic
1862 srcbase = get_polymorphed_reg(RA, 64, 0)
1863 # RB *is* polymorphic
1864 offs = get_polymorphed_reg(RB, svctx.src_elwidth, i)
1866 if svctx.SEA: offs = sext(offs, svctx.src_elwidth, 64)
1868 # takes care of (merges) processor LE/BE and ld/ldbrx
1869 bytereverse = brev XNOR MSR.LE
1871 # read the underlying memory
1872 memread <= MEM(srcbase + offs, op_width)
1874 # optionally performs byteswap at op width
1876 memread = byteswap(memread, op_width)
1878 if svpctx.saturation_mode:
1879 # ... saturation adjustment...
1880 memread = clamp(memread, op_width, svctx.dest_elwidth)
1882 # truncate/extend to over-ridden dest width.
1883 memread = adjust_wid(memread, op_width, svctx.dest_elwidth)
1885 # takes care of inserting memory-read (now correctly byteswapped)
1886 # into regfile underlying LE-defined order, into the right place
1887 # within the NEON-like register, respecting destination element
1888 # bitwidth, and the element index (j)
1889 set_polymorphed_reg(RT, svctx.dest_elwidth, j, memread)
1891 # increments both src and dest element indices (no predication here)
1898 In the [[sv/remap]] page the concept of "Remapping" is described. Whilst
1899 it is expensive to set up (2 64-bit opcodes minimum) it provides a way to
1900 arbitrarily perform 1D, 2D and 3D "remapping" of up to 64 elements worth
1901 of LDs or STs. The usual interest in such re-mapping is for example in
1902 separating out 24-bit RGB channel data into separate contiguous registers.
1904 REMAP easily covers this capability, and with dest elwidth overrides
1905 and saturation may do so with built-in conversion that would normally
1906 require additional width-extension, sign-extension and min/max Vectorised
1907 instructions as post-processing stages.
1909 Thus we do not need to provide specialist LD/ST "Structure Packed" opcodes
1910 because the generic abstracted concept of "Remapping", when applied to
1911 LD/ST, will give that same capability, with far more flexibility.
1913 It is worth noting that Pack/Unpack Modes of SVSTATE, which may be
1914 established through `svstep`, are also an easy way to perform regular
1915 Structure Packing, at the vec2/vec3/vec4 granularity level. Beyond that,
1916 REMAP will need to be used.
1922 # Condition Register SVP64 Operations
1924 Condition Register Fields are only 4 bits wide: this presents some
1925 interesting conceptual challenges for SVP64, which was designed
1926 primarily for vectors of arithmetic and logical operations. However
1927 if predicates may be bits of CR Fields it makes sense to extend
1928 Simple-V to cover CR Operations, especially given that Vectorised Rc=1
1929 may be processed by Vectorised CR Operations tbat usefully in turn
1930 may become Predicate Masks to yet more Vector operations, like so:
1933 sv.cmpi/ew=8 *B,*ra,0 # compare bytes against zero
1934 sv.cmpi/ew=8 *B2,*ra,13. # and against newline
1935 sv.cror PM.EQ,B.EQ,B2.EQ # OR compares to create mask
1936 sv.stb/sm=EQ ... # store only nonzero/newline
1939 Element width however is clearly meaningless for a 4-bit collation of
1940 Conditions, EQ LT GE SO. Likewise, arithmetic saturation (an important
1941 part of Arithmetic SVP64) has no meaning. An alternative Mode Format is
1942 required, and given that elwidths are meaningless for CR Fields the bits
1943 in SVP64 `RM` may be used for other purposes.
1945 This alternative mapping **only** applies to instructions that **only**
1946 reference a CR Field or CR bit as the sole exclusive result. This section
1947 **does not** apply to instructions which primarily produce arithmetic
1948 results that also, as an aside, produce a corresponding CR Field (such as
1949 when Rc=1). Instructions that involve Rc=1 are definitively arithmetic
1950 in nature, where the corresponding Condition Register Field can be
1951 considered to be a "co-result". Such CR Field "co-result" arithmeric
1952 operations are firmly out of scope for this section, being covered fully
1955 * Examples of v3.0B instructions to which this section does
1957 - `mfcr` and `cmpi` (3 bit operands) and
1958 - `crnor` and `crand` (5 bit operands).
1959 * Examples to which this section does **not** apply include
1960 `fadds.` and `subf.` which both produce arithmetic results
1961 (and a CR Field co-result).
1963 The CR Mode Format still applies to `sv.cmpi` because despite
1964 taking a GPR as input, the output from the Base Scalar v3.0B `cmpi`
1965 instruction is purely to a Condition Register Field.
1967 Other modes are still applicable and include:
1969 * **Data-dependent fail-first**.
1970 useful to truncate VL based on analysis of a Condition Register result bit.
1972 Reduction is useful for analysing a Vector of Condition Register Fields
1973 and reducing it to one single Condition Register Field.
1975 Predicate-result does not make any sense because when Rc=1 a co-result
1976 is created (a CR Field). Testing the co-result allows the decision to
1977 be made to store or not store the main result, and for CR Ops the CR
1978 Field result *is* the main result.
1982 SVP64 RM `MODE` (includes `ELWIDTH_SRC` bits) for CR-based operations:
1984 |6 | 7 |19-20| 21 | 22 23 | description |
1985 |--|---|-----| --- |---------|----------------- |
1986 |/ | / |0 RG | 0 | dz sz | simple mode |
1987 |/ | / |0 RG | 1 | dz sz | scalar reduce mode (mapreduce) |
1988 |zz|SNZ|1 VLI| inv | CR-bit | Ffirst 3-bit mode |
1989 |/ |SNZ|1 VLI| inv | dz sz | Ffirst 5-bit mode (implies CR-bit from result) |
1993 * **sz / dz** if predication is enabled will put zeros into the dest
1994 (or as src in the case of twin pred) when the predicate bit is zero.
1995 otherwise the element is ignored or skipped, depending on context.
1996 * **zz** set both sz and dz equal to this flag
1997 * **SNZ** In fail-first mode, on the bit being tested, when sz=1 and
1998 SNZ=1 a value "1" is put in place of "0".
1999 * **inv CR-bit** just as in branches (BO) these bits allow testing of
2000 a CR bit and whether it is set (inv=0) or unset (inv=1)
2001 * **RG** inverts the Vector Loop order (VL-1 downto 0) rather
2002 than the normal 0..VL-1
2003 * **SVM** sets "subvector" reduce mode
2004 * **VLi** VL inclusive: in fail-first mode, the truncation of
2005 VL *includes* the current element at the failure point rather
2006 than excludes it from the count.
2008 ## Data-dependent fail-first on CR operations
2010 The principle of data-dependent fail-first is that if, during the course
2011 of sequentially evaluating an element's Condition Test, one such test
2012 is encountered which fails, then VL (Vector Length) is truncated (set)
2013 at that point. In the case of Arithmetic SVP64 Operations the Condition
2014 Register Field generated from Rc=1 is used as the basis for the truncation
2015 decision. However with CR-based operations that CR Field result to be
2016 tested is provided *by the operation itself*.
2018 Data-dependent SVP64 Vectorised Operations involving the creation
2019 or modification of a CR can require an extra two bits, which are not
2020 available in the compact space of the SVP64 RM `MODE` Field. With the
2021 concept of element width overrides being meaningless for CR Fields it
2022 is possible to use the `ELWIDTH` field for alternative purposes.
2024 Condition Register based operations such as `sv.mfcr` and `sv.crand`
2025 can thus be made more flexible. However the rules that apply in this
2026 section also apply to future CR-based instructions.
2028 There are two primary different types of CR operations:
2030 * Those which have a 3-bit operand field (referring to a CR Field)
2031 * Those which have a 5-bit operand (referring to a bit within the
2034 Examining these two types it is observed that the difference may
2035 be considered to be that the 5-bit variant *already* provides the
2036 prerequisite information about which CR Field bit (EQ, GE, LT, SO) is
2037 to be operated on by the instruction. Thus, logically, we may set the
2040 * When a 5-bit CR Result field is used in an instruction, the
2041 5-bit variant of Data-Dependent Fail-First
2042 must be used. i.e. the bit of the CR field to be tested is
2043 the one that has just been modified (created) by the operation.
2044 * When a 3-bit CR Result field is used the 3-bit variant
2045 must be used, providing as it does the missing `CRbit` field
2046 in order to select which CR Field bit of the result shall
2047 be tested (EQ, LE, GE, SO)
2049 The reason why the 3-bit CR variant needs the additional CR-bit field
2050 should be obvious from the fact that the 3-bit CR Field from the base
2051 Power ISA v3.0B operation clearly does not contain and is missing the
2052 two CR Field Selector bits. Thus, these two bits (to select EQ, LE,
2053 GE or SO) must be provided in another way.
2055 Examples of the former type:
2057 * crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
2058 to be tested against `inv` is the one selected by `BT`
2059 * mcrf. This has only 3-bit (BF, BFA). In order to select the
2060 bit to be tested, the alternative encoding must be used.
2061 With `CRbit` coming from the SVP64 RM bits 22-23 the bit
2062 of BF to be tested is identified.
2064 Just as with SVP64 [[sv/branches]] there is the option to truncate
2065 VL to include the element being tested (`VLi=1`) and to exclude it
2068 Also exactly as with [[sv/normal]] fail-first, VL cannot, unlike
2069 [[sv/ldst]], be set to an arbitrary value. Deterministic behaviour
2072 ## Reduction and Iteration
2074 Bearing in mind as described in the svp64 Appendix, SVP64 Horizontal
2075 Reduction is a deterministic schedule on top of base Scalar v3.0
2076 operations, the same rules apply to CR Operations, i.e. that programmers
2077 must follow certain conventions in order for an *end result* of a
2078 reduction to be achieved. Unlike other Vector ISAs *there are no explicit
2079 reduction opcodes* in SVP64: Schedules however achieve the same effect.
2081 Due to these conventions only reduction on operations such as `crand`
2082 and `cror` are meaningful because these have Condition Register Fields
2083 as both input and output. Meaningless operations are not prohibited
2084 because the cost in hardware of doing so is prohibitive, but neither
2085 are they `UNDEFINED`. Implementations are still required to execute them
2086 but are at liberty to optimise out any operations that would ultimately
2087 be overwritten, as long as Strict Program Order is still obvservable by
2090 Also bear in mind that 'Reverse Gear' may be enabled, which can be
2091 used in combination with overlapping CR operations to iteratively
2092 accumulate results. Issuing a `sv.crand` operation for example with
2093 `BA` differing from `BB` by one Condition Register Field would result
2094 in a cascade effect, where the first-encountered CR Field would set the
2095 result to zero, and also all subsequent CR Field elements thereafter:
2098 # sv.crand/mr/rg CR4.ge.v, CR5.ge.v, CR4.ge.v
2099 for i in VL-1 downto 0 # reverse gear
2100 CR.field[4+i].ge &= CR.field[5+i].ge
2103 `sv.crxor` with reduction would be particularly useful for parity
2104 calculation for example, although there are many ways in which the same
2105 calculation could be carried out after transferring a vector of CR Fields
2106 to a GPR using crweird operations.
2108 Implementations are free and clear to optimise these reductions in any way
2109 they see fit, as long as the end-result is compatible with Strict Program
2110 Order being observed, and Interrupt latency is not adversely impacted.
2112 ## Unusual and quirky CR operations
2114 **cmp and other compare ops**
2116 `cmp` and `cmpi` etc take GPRs as sources and create a CR Field as a result.
2121 With `ELWIDTH` applying to the source GPR operands this is perfectly fine.
2123 **crweird operations**
2125 There are 4 weird CR-GPR operations and one reasonable one in
2126 the [[cr_int_predication]] set:
2132 * mcrfm - reasonably normal and referring to CR Fields for src and dest.
2134 The "weird" operations have a non-standard behaviour, being able to
2135 treat *individual bits* of a GPR effectively as elements. They are
2136 expected to be Micro-coded by most Hardware implementations.
2143 # SVP64 Branch Conditional behaviour
2145 Please note: although similar, SVP64 Branch instructions should be
2146 considered completely separate and distinct from standard scalar
2147 OpenPOWER-approved v3.0B branches. **v3.0B branches are in no way
2148 impacted, altered, changed or modified in any way, shape or form by the
2149 SVP64 Vectorised Variants**.
2151 It is also extremely important to note that Branches are the sole
2152 pseudo-exception in SVP64 to `Scalar Identity Behaviour`. SVP64 Branches
2153 contain additional modes that are useful for scalar operations (i.e. even
2154 when VL=1 or when using single-bit predication).
2158 Scalar 3.0B Branch Conditional operations, `bc`, `bctar` etc. test
2159 a Condition Register. However for parallel processing it is simply
2160 impossible to perform multiple independent branches: the Program
2161 Counter simply cannot branch to multiple destinations based on multiple
2162 conditions. The best that can be done is to test multiple Conditions
2163 and make a decision of a *single* branch, based on analysis of a *Vector*
2164 of CR Fields which have just been calculated from a *Vector* of results.
2166 In 3D Shader binaries, which are inherently parallelised and predicated,
2167 testing all or some results and branching based on multiple tests is
2168 extremely common, and a fundamental part of Shader Compilers. Example:
2169 without such multi-condition test-and-branch, if a predicate mask is
2170 all zeros a large batch of instructions may be masked out to `nop`,
2171 and it would waste CPU cycles to run them. 3D GPU ISAs can test for
2172 this scenario and, with the appropriate predicate-analysis instruction,
2173 jump over fully-masked-out operations, by spotting that *all* Conditions
2176 Unless Branches are aware and capable of such analysis, additional
2177 instructions would be required which perform Horizontal Cumulative
2178 analysis of Vectorised Condition Register Fields, in order to reduce
2179 the Vector of CR Fields down to one single yes or no decision that a
2180 Scalar-only v3.0B Branch-Conditional could cope with. Such instructions
2181 would be unavoidable, required, and costly by comparison to a single
2182 Vector-aware Branch. Therefore, in order to be commercially competitive,
2183 `sv.bc` and other Vector-aware Branch Conditional instructions are a
2184 high priority for 3D GPU (and OpenCL-style) workloads.
2186 Given that Power ISA v3.0B is already quite powerful, particularly
2187 the Condition Registers and their interaction with Branches, there are
2188 opportunities to create extremely flexible and compact Vectorised Branch
2189 behaviour. In addition, the side-effects (updating of CTR, truncation
2190 of VL, described below) make it a useful instruction even if the branch
2191 points to the next instruction (no actual branch).
2195 When considering an "array" of branch-tests, there are four
2196 primarily-useful modes: AND, OR, NAND and NOR of all Conditions.
2197 NAND and NOR may be synthesised from AND and OR by inverting `BO[1]`
2198 which just leaves two modes:
2200 * Branch takes place on the **first** CR Field test to succeed
2201 (a Great Big OR of all condition tests). Exit occurs
2202 on the first **successful** test.
2203 * Branch takes place only if **all** CR field tests succeed:
2204 a Great Big AND of all condition tests. Exit occurs
2205 on the first **failed** test.
2207 Early-exit is enacted such that the Vectorised Branch does not
2208 perform needless extra tests, which will help reduce reads on
2209 the Condition Register file.
2211 *Note: Early-exit is **MANDATORY** (required) behaviour. Branches
2212 **MUST** exit at the first sequentially-encountered failure point,
2213 for exactly the same reasons for which it is mandatory in programming
2214 languages doing early-exit: to avoid damaging side-effects and to provide
2215 deterministic behaviour. Speculative testing of Condition Register
2216 Fields is permitted, as is speculative calculation of CTR, as long as,
2217 as usual in any Out-of-Order microarchitecture, that speculative testing
2218 is cancelled should an early-exit occur. i.e. the speculation must be
2219 "precise": Program Order must be preserved*
2221 Also note that when early-exit occurs in Horizontal-first Mode, srcstep,
2222 dststep etc. are all reset, ready to begin looping from the beginning
2223 for the next instruction. However for Vertical-first Mode srcstep
2224 etc. are incremented "as usual" i.e. an early-exit has no special impact,
2225 regardless of whether the branch occurred or not. This can leave srcstep
2226 etc. in what may be considered an unusual state on exit from a loop and
2227 it is up to the programmer to reset srcstep, dststep etc. to known-good
2228 values *(easily achieved with `setvl`)*.
2230 Additional useful behaviour involves two primary Modes (both of which
2231 may be enabled and combined):
2233 * **VLSET Mode**: identical to Data-Dependent Fail-First Mode
2234 for Arithmetic SVP64 operations, with more
2235 flexibility and a close interaction and integration into the
2236 underlying base Scalar v3.0B Branch instruction.
2237 Truncation of VL takes place around the early-exit point.
2238 * **CTR-test Mode**: gives much more flexibility over when and why
2239 CTR is decremented, including options to decrement if a Condition
2240 test succeeds *or if it fails*.
2242 With these side-effects, basic Boolean Logic Analysis advises that it
2243 is important to provide a means to enact them each based on whether
2244 testing succeeds *or fails*. This results in a not-insignificant number
2245 of additional Mode Augmentation bits, accompanying VLSET and CTR-test
2248 Predicate skipping or zeroing may, as usual with SVP64, be controlled by
2249 `sz`. Where the predicate is masked out and zeroing is enabled, then in
2250 such circumstances the same Boolean Logic Analysis dictates that rather
2251 than testing only against zero, the option to test against one is also
2252 prudent. This introduces a new immediate field, `SNZ`, which works in
2253 conjunction with `sz`.
2255 Vectorised Branches can be used in either SVP64 Horizontal-First or
2256 Vertical-First Mode. Essentially, at an element level, the behaviour
2257 is identical in both Modes, although the `ALL` bit is meaningless in
2258 Vertical-First Mode.
2260 It is also important to bear in mind that, fundamentally, Vectorised
2261 Branch-Conditional is still extremely close to the Scalar v3.0B
2262 Branch-Conditional instructions, and that the same v3.0B Scalar
2263 Branch-Conditional instructions are still *completely separate and
2264 independent*, being unaltered and unaffected by their SVP64 variants in
2265 every conceivable way.
2267 *Programming note: One important point is that SVP64 instructions are
2268 64 bit. (8 bytes not 4). This needs to be taken into consideration
2269 when computing branch offsets: the offset is relative to the start of
2270 the instruction, which **includes** the SVP64 Prefix*
2272 ## Format and fields
2274 With element-width overrides being meaningless for Condition Register
2275 Fields, bits 4 thru 7 of SVP64 RM may be used for additional Mode bits.
2277 SVP64 RM `MODE` (includes repurposing `ELWIDTH` bits 4:5, and
2278 `ELWIDTH_SRC` bits 6-7 for *alternate* uses) for Branch Conditional:
2280 | 4 | 5 | 6 | 7 | 17 | 18 | 19 | 20 | 21 | 22 23 | description |
2281 | - | - | - | - | -- | -- | -- | -- | --- |--------|----------------- |
2282 |ALL|SNZ| / | / | SL |SLu | 0 | 0 | / | LRu sz | simple mode |
2283 |ALL|SNZ| / |VSb| SL |SLu | 0 | 1 | VLI | LRu sz | VLSET mode |
2284 |ALL|SNZ|CTi| / | SL |SLu | 1 | 0 | / | LRu sz | CTR-test mode |
2285 |ALL|SNZ|CTi|VSb| SL |SLu | 1 | 1 | VLI | LRu sz | CTR-test+VLSET mode |
2287 Brief description of fields:
2289 * **sz=1** if predication is enabled and `sz=1` and a predicate
2290 element bit is zero, `SNZ` will
2291 be substituted in place of the CR bit selected by `BI`,
2292 as the Condition tested.
2294 normal SVP64 `sz=1` behaviour, where *only* a zero is put in
2295 place of masked-out predicate bits.
2296 * **sz=0** When `sz=0` skipping occurs as usual on
2297 masked-out elements, but unlike all
2298 other SVP64 behaviour which entirely skips an element with
2299 no related side-effects at all, there are certain
2300 special circumstances where CTR
2301 may be decremented. See CTR-test Mode, below.
2302 * **ALL** when set, all branch conditional tests must pass in order for
2303 the branch to succeed. When clear, it is the first sequentially
2304 encountered successful test that causes the branch to succeed.
2305 This is identical behaviour to how programming languages perform
2306 early-exit on Boolean Logic chains.
2307 * **VLI** VLSET is identical to Data-dependent Fail-First mode.
2308 In VLSET mode, VL *may* (depending on `VSb`) be truncated.
2309 If VLI (Vector Length Inclusive) is clear,
2310 VL is truncated to *exclude* the current element, otherwise it is
2311 included. SVSTATE.MVL is not altered: only VL.
2312 * **SL** identical to `LR` except applicable to SVSTATE. If `SL`
2313 is set, SVSTATE is transferred to SVLR (conditionally on
2314 whether `SLu` is set).
2315 * **SLu**: SVSTATE Link Update, like `LRu` except applies to SVSTATE.
2316 * **LRu**: Link Register Update, used in conjunction with LK=1
2317 to make LR update conditional
2318 * **VSb** In VLSET Mode, after testing,
2319 if VSb is set, VL is truncated if the test succeeds. If VSb is clear,
2320 VL is truncated if a test *fails*. Masked-out (skipped)
2321 bits are not considered
2322 part of testing when `sz=0`
2323 * **CTi** CTR inversion. CTR-test Mode normally decrements per element
2324 tested. CTR inversion decrements if a test *fails*. Only relevant
2327 LRu and CTR-test modes are where SVP64 Branches subtly differ from
2328 Scalar v3.0B Branches. `sv.bcl` for example will always update LR,
2329 whereas `sv.bcl/lru` will only update LR if the branch succeeds.
2331 Of special interest is that when using ALL Mode (Great Big AND of all
2332 Condition Tests), if `VL=0`, which is rare but can occur in Data-Dependent
2333 Modes, the Branch will always take place because there will be no failing
2334 Condition Tests to prevent it. Likewise when not using ALL Mode (Great
2335 Big OR of all Condition Tests) and `VL=0` the Branch is guaranteed not
2336 to occur because there will be no *successful* Condition Tests to make
2339 ## Vectorised CR Field numbering, and Scalar behaviour
2341 It is important to keep in mind that just like all SVP64 instructions,
2342 the `BI` field of the base v3.0B Branch Conditional instruction may be
2343 extended by SVP64 EXTRA augmentation, as well as be marked as either
2344 Scalar or Vector. It is also crucially important to keep in mind that for
2345 CRs, SVP64 sequentially increments the CR *Field* numbers. CR *Fields*
2346 are treated as elements, not bit-numbers of the CR *register*.
2348 The `BI` operand of Branch Conditional operations is five bits, in scalar
2349 v3.0B this would select one bit of the 32 bit CR, comprising eight CR
2350 Fields of 4 bits each. In SVP64 there are 16 32 bit CRs, containing
2351 128 4-bit CR Fields. Therefore, the 2 LSBs of `BI` select the bit from
2352 the CR Field (EQ LT GT SO), and the top 3 bits are extended to either
2353 scalar or vector and to select CR Fields 0..127 as specified in SVP64
2354 [[sv/svp64/appendix]].
2356 When the CR Fields selected by SVP64-Augmented `BI` is marked as scalar,
2357 then as the usual SVP64 rules apply: the Vector loop ends at the first
2358 element tested (the first CR *Field*), after taking predication into
2359 consideration. Thus, also as usual, when a predicate mask is given, and
2360 `BI` marked as scalar, and `sz` is zero, srcstep skips forward to the
2361 first non-zero predicated element, and only that one element is tested.
2363 In other words, the fact that this is a Branch Operation (instead of an
2364 arithmetic one) does not result, ultimately, in significant changes as
2365 to how SVP64 is fundamentally applied, except with respect to:
2367 * the unique properties associated with conditionally
2368 changing the Program Counter (aka "a Branch"), resulting in early-out
2372 Both are outlined below, in later sections.
2374 ## Horizontal-First and Vertical-First Modes
2376 In SVP64 Horizontal-First Mode, the first failure in ALL mode (Great Big
2377 AND) results in early exit: no more updates to CTR occur (if requested);
2378 no branch occurs, and LR is not updated (if requested). Likewise for
2379 non-ALL mode (Great Big Or) on first success early exit also occurs,
2380 however this time with the Branch proceeding. In both cases the testing
2381 of the Vector of CRs should be done in linear sequential order (or in
2382 REMAP re-sequenced order): such that tests that are sequentially beyond
2383 the exit point are *not* carried out. (*Note: it is standard practice
2384 in Programming languages to exit early from conditional tests, however a
2385 little unusual to consider in an ISA that is designed for Parallel Vector
2386 Processing. The reason is to have strictly-defined guaranteed behaviour*)
2388 In Vertical-First Mode, setting the `ALL` bit results in `UNDEFINED`
2389 behaviour. Given that only one element is being tested at a time in
2390 Vertical-First Mode, a test designed to be done on multiple bits is
2393 ## Description and Modes
2395 Predication in both INT and CR modes may be applied to `sv.bc` and other
2396 SVP64 Branch Conditional operations, exactly as they may be applied to
2397 other SVP64 operations. When `sz` is zero, any masked-out Branch-element
2398 operations are not included in condition testing, exactly like all other
2399 SVP64 operations, *including* side-effects such as potentially updating
2400 LR or CTR, which will also be skipped. There is *one* exception here,
2401 which is when `BO[2]=0, sz=0, CTR-test=0, CTi=1` and the relevant element
2402 predicate mask bit is also zero: under these special circumstances CTR
2403 will also decrement.
2405 When `sz` is non-zero, this normally requests insertion of a zero in
2406 place of the input data, when the relevant predicate mask bit is zero.
2407 This would mean that a zero is inserted in place of `CR[BI+32]` for
2408 testing against `BO`, which may not be desirable in all circumstances.
2409 Therefore, an extra field is provided `SNZ`, which, if set, will insert
2410 a **one** in place of a masked-out element, instead of a zero.
2412 (*Note: Both options are provided because it is useful to deliberately
2413 cause the Branch-Conditional Vector testing to fail at a specific point,
2414 controlled by the Predicate mask. This is particularly useful in `VLSET`
2415 mode, which will truncate SVSTATE.VL at the point of the first failed
2418 Normally, CTR mode will decrement once per Condition Test, resulting under
2419 normal circumstances that CTR reduces by up to VL in Horizontal-First
2420 Mode. Just as when v3.0B Branch-Conditional saves at least one instruction
2421 on tight inner loops through auto-decrementation of CTR, likewise it
2422 is also possible to save instruction count for SVP64 loops in both
2423 Vertical-First and Horizontal-First Mode, particularly in circumstances
2424 where there is conditional interaction between the element computation
2425 and testing, and the continuation (or otherwise) of a given loop. The
2426 potential combinations of interactions is why CTR testing options have
2429 Also, the unconditional bit `BO[0]` is still relevant when Predication
2430 is applied to the Branch because in `ALL` mode all nonmasked bits have
2431 to be tested, and when `sz=0` skipping occurs. Even when VLSET mode is
2432 not used, CTR may still be decremented by the total number of nonmasked
2433 elements, acting in effect as either a popcount or cntlz depending
2434 on which mode bits are set. In short, Vectorised Branch becomes an
2435 extremely powerful tool.
2437 **Micro-Architectural Implementation Note**: *when implemented on top
2438 of a Multi-Issue Out-of-Order Engine it is possible to pass a copy of
2439 the predicate and the prerequisite CR Fields to all Branch Units, as
2440 well as the current value of CTR at the time of multi-issue, and for
2441 each Branch Unit to compute how many times CTR would be subtracted,
2442 in a fully-deterministic and parallel fashion. A SIMD-based Branch
2443 Unit, receiving and processing multiple CR Fields covered by multiple
2444 predicate bits, would do the exact same thing. Obviously, however, if
2445 CTR is modified within any given loop (mtctr) the behaviour of CTR is
2446 no longer deterministic.*
2448 ### Link Register Update
2450 For a Scalar Branch, unconditional updating of the Link Register LR
2451 is useful and practical. However, if a loop of CR Fields is tested,
2452 unconditional updating of LR becomes problematic.
2454 For example when using `bclr` with `LRu=1,LK=0` in Horizontal-First Mode,
2455 LR's value will be unconditionally overwritten after the first element,
2456 such that for execution (testing) of the second element, LR has the value
2457 `CIA+8`. This is covered in the `bclrl` example, in a later section.
2459 The addition of a LRu bit modifies behaviour in conjunction with LK,
2462 * `sv.bc` When LRu=0,LK=0, Link Register is not updated
2463 * `sv.bcl` When LRu=0,LK=1, Link Register is updated unconditionally
2464 * `sv.bcl/lru` When LRu=1,LK=1, Link Register will
2465 only be updated if the Branch Condition fails.
2466 * `sv.bc/lru` When LRu=1,LK=0, Link Register will only be updated if
2467 the Branch Condition succeeds.
2469 This avoids destruction of LR during loops (particularly Vertical-First
2472 **SVLR and SVSTATE**
2474 For precisely the reasons why `LK=1` was added originally to the Power
2475 ISA, with SVSTATE being a peer of the Program Counter it becomes necessary
2476 to also add an SVLR (SVSTATE Link Register) and corresponding control bits
2481 Where a standard Scalar v3.0B branch unconditionally decrements CTR when
2482 `BO[2]` is clear, CTR-test Mode introduces more flexibility which allows
2483 CTR to be used for many more types of Vector loops constructs.
2485 CTR-test mode and CTi interaction is as follows: note that `BO[2]`
2486 is still required to be clear for CTR decrements to be considered,
2487 exactly as is the case in Scalar Power ISA v3.0B
2489 * **CTR-test=0, CTi=0**: CTR decrements on a per-element basis
2490 if `BO[2]` is zero. Masked-out elements when `sz=0` are
2491 skipped (i.e. CTR is *not* decremented when the predicate
2492 bit is zero and `sz=0`).
2493 * **CTR-test=0, CTi=1**: CTR decrements on a per-element basis
2494 if `BO[2]` is zero and a masked-out element is skipped
2495 (`sz=0` and predicate bit is zero). This one special case is the
2496 **opposite** of other combinations, as well as being
2497 completely different from normal SVP64 `sz=0` behaviour)
2498 * **CTR-test=1, CTi=0**: CTR decrements on a per-element basis
2499 if `BO[2]` is zero and the Condition Test succeeds.
2500 Masked-out elements when `sz=0` are skipped (including
2501 not decrementing CTR)
2502 * **CTR-test=1, CTi=1**: CTR decrements on a per-element basis
2503 if `BO[2]` is zero and the Condition Test *fails*.
2504 Masked-out elements when `sz=0` are skipped (including
2505 not decrementing CTR)
2507 `CTR-test=0, CTi=1, sz=0` requires special emphasis because it is the
2508 only time in the entirety of SVP64 that has side-effects when
2509 a predicate mask bit is clear. **All** other SVP64 operations
2510 entirely skip an element when sz=0 and a predicate mask bit is zero.
2511 It is also critical to emphasise that in this unusual mode,
2512 no other side-effects occur: **only** CTR is decremented, i.e. the
2513 rest of the Branch operation is skipped.
2517 VLSET Mode truncates the Vector Length so that subsequent instructions
2518 operate on a reduced Vector Length. This is similar to Data-dependent
2519 Fail-First and LD/ST Fail-First, where for VLSET the truncation occurs
2520 at the Branch decision-point.
2522 Interestingly, due to the side-effects of `VLSET` mode it is actually
2523 useful to use Branch Conditional even to perform no actual branch
2524 operation, i.e to point to the instruction after the branch. Truncation of
2525 VL would thus conditionally occur yet control flow alteration would not.
2527 `VLSET` mode with Vertical-First is particularly unusual. Vertical-First
2528 is designed to be used for explicit looping, where an explicit call to
2529 `svstep` is required to move both srcstep and dststep on to the next
2530 element, until VL (or other condition) is reached. Vertical-First Looping
2531 is expected (required) to terminate if the end of the Vector, VL, is
2532 reached. If however that loop is terminated early because VL is truncated,
2533 VLSET with Vertical-First becomes meaningless. Resolving this would
2534 require two branches: one Conditional, the other branching unconditionally
2535 to create the loop, where the Conditional one jumps over it.
2537 Therefore, with `VSb`, the option to decide whether truncation should
2538 occur if the branch succeeds *or* if the branch condition fails allows
2539 for the flexibility required. This allows a Vertical-First Branch to
2540 *either* be used as a branch-back (loop) *or* as part of a conditional
2541 exit or function call from *inside* a loop, and for VLSET to be integrated
2542 into both types of decision-making.
2544 In the case of a Vertical-First branch-back (loop), with `VSb=0` the
2545 branch takes place if success conditions are met, but on exit from that
2546 loop (branch condition fails), VL will be truncated. This is extremely
2549 `VLSET` mode with Horizontal-First when `VSb=0` is still useful, because
2550 it can be used to truncate VL to the first predicated (non-masked-out)
2553 The truncation point for VL, when VLi is clear, must not include skipped
2554 elements that preceded the current element being tested. Example:
2555 `sz=0, VLi=0, predicate mask = 0b110010` and the Condition Register
2556 failure point is at CR Field element 4.
2558 * Testing at element 0 is skipped because its predicate bit is zero
2559 * Testing at element 1 passed
2560 * Testing elements 2 and 3 are skipped because their
2561 respective predicate mask bits are zero
2562 * Testing element 4 fails therefore VL is truncated to **2**
2563 not 4 due to elements 2 and 3 being skipped.
2565 If `sz=1` in the above example *then* VL would have been set to 4 because
2566 in non-zeroing mode the zero'd elements are still effectively part of the
2567 Vector (with their respective elements set to `SNZ`)
2569 If `VLI=1` then VL would be set to 5 regardless of sz, due to being inclusive
2570 of the element actually being tested.
2572 ### VLSET and CTR-test combined
2574 If both CTR-test and VLSET Modes are requested, it is important to
2575 observe the correct order. What occurs depends on whether VLi is enabled,
2576 because VLi affects the length, VL.
2578 If VLi (VL truncate inclusive) is set:
2580 1. compute the test including whether CTR triggers
2581 2. (optionally) decrement CTR
2582 3. (optionally) truncate VL (VSb inverts the decision)
2583 4. decide (based on step 1) whether to terminate looping
2584 (including not executing step 5)
2585 5. decide whether to branch.
2587 If VLi is clear, then when a test fails that element
2588 and any following it
2589 should **not** be considered part of the Vector. Consequently:
2591 1. compute the branch test including whether CTR triggers
2592 2. if the test fails against VSb, truncate VL to the *previous*
2593 element, and terminate looping. No further steps executed.
2594 3. (optionally) decrement CTR
2595 4. decide whether to branch.
2597 ## Boolean Logic combinations
2599 In a Scalar ISA, Branch-Conditional testing even of vector results may be
2600 performed through inversion of tests. NOR of all tests may be performed
2601 by inversion of the scalar condition and branching *out* from the scalar
2602 loop around elements, using scalar operations.
2604 In a parallel (Vector) ISA it is the ISA itself which must perform
2605 the prerequisite logic manipulation. Thus for SVP64 there are an
2606 extraordinary number of nesessary combinations which provide completely
2607 different and useful behaviour. Available options to combine:
2609 * `BO[0]` to make an unconditional branch would seem irrelevant if
2610 it were not for predication and for side-effects (CTR Mode
2612 * Enabling CTR-test Mode and setting `BO[2]` can still result in the
2614 taking place, not because the Condition Test itself failed, but
2615 because CTR reached zero **because**, as required by CTR-test mode,
2616 CTR was decremented as a **result** of Condition Tests failing.
2617 * `BO[1]` to select whether the CR bit being tested is zero or nonzero
2618 * `R30` and `~R30` and other predicate mask options including CR and
2619 inverted CR bit testing
2620 * `sz` and `SNZ` to insert either zeros or ones in place of masked-out
2622 * `ALL` or `ANY` behaviour corresponding to `AND` of all tests and
2623 `OR` of all tests, respectively.
2624 * Predicate Mask bits, which combine in effect with the CR being
2626 * Inversion of Predicate Masks (`~r3` instead of `r3`, or using
2627 `NE` rather than `EQ`) which results in an additional
2628 level of possible ANDing, ORing etc. that would otherwise
2629 need explicit instructions.
2631 The most obviously useful combinations here are to set `BO[1]` to zero
2632 in order to turn `ALL` into Great-Big-NAND and `ANY` into Great-Big-NOR.
2633 Other Mode bits which perform behavioural inversion then have to work
2634 round the fact that the Condition Testing is NOR or NAND. The alternative
2635 to not having additional behavioural inversion (`SNZ`, `VSb`, `CTi`)
2636 would be to have a second (unconditional) branch directly after the first,
2637 which the first branch jumps over. This contrivance is avoided by the
2638 behavioural inversion bits.
2640 ## Pseudocode and examples
2642 Please see the SVP64 appendix regarding CR bit ordering and for
2643 the definition of `CR{n}`
2645 For comparative purposes this is a copy of the v3.0B `bc` pseudocode
2648 if (mode_is_64bit) then M <- 0
2650 if ¬BO[2] then CTR <- CTR - 1
2651 ctr_ok <- BO[2] | ((CTR[M:63] != 0) ^ BO[3])
2652 cond_ok <- BO[0] | ¬(CR[BI+32] ^ BO[1])
2653 if ctr_ok & cond_ok then
2654 if AA then NIA <-iea EXTS(BD || 0b00)
2655 else NIA <-iea CIA + EXTS(BD || 0b00)
2656 if LK then LR <-iea CIA + 4
2659 Simplified pseudocode including LRu and CTR skipping, which illustrates
2660 clearly that SVP64 Scalar Branches (VL=1) are **not** identical to
2661 v3.0B Scalar Branches. The key areas where differences occur are the
2662 inclusion of predication (which can still be used when VL=1), in when and
2663 why CTR is decremented (CTRtest Mode) and whether LR is updated (which
2664 is unconditional in v3.0B when LK=1, and conditional in SVP64 when LRu=1).
2666 Inline comments highlight the fact that the Scalar Branch behaviour and
2667 pseudocode is still clearly visible and embedded within the Vectorised
2671 if (mode_is_64bit) then M <- 0
2673 # the bit of CR to test, if the predicate bit is zero,
2676 if ¬predicate_bit then testbit = SVRMmode.SNZ
2677 # otherwise apart from the override ctr_ok and cond_ok
2678 # are exactly the same
2679 ctr_ok <- BO[2] | ((CTR[M:63] != 0) ^ BO[3])
2680 cond_ok <- BO[0] | ¬(testbit ^ BO[1])
2681 if ¬predicate_bit & ¬SVRMmode.sz then
2682 # this is entirely new: CTR-test mode still decrements CTR
2683 # even when predicate-bits are zero
2684 if ¬BO[2] & CTRtest & ¬CTi then
2686 # instruction finishes here
2688 # usual BO[2] CTR-mode now under CTR-test mode as well
2689 if ¬BO[2] & ¬(CTRtest & (cond_ok ^ CTi)) then CTR <- CTR - 1
2690 # new VLset mode, conditional test truncates VL
2691 if VLSET and VSb = (cond_ok & ctr_ok) then
2692 if SVRMmode.VLI then SVSTATE.VL = srcstep+1
2693 else SVSTATE.VL = srcstep
2694 # usual LR is now conditional, but also joined by SVLR
2696 svlr_ok <- SVRMmode.SL
2697 if ctr_ok & cond_ok then
2698 if AA then NIA <-iea EXTS(BD || 0b00)
2699 else NIA <-iea CIA + EXTS(BD || 0b00)
2700 if SVRMmode.LRu then lr_ok <- ¬lr_ok
2701 if SVRMmode.SLu then svlr_ok <- ¬svlr_ok
2702 if lr_ok then LR <-iea CIA + 4
2703 if svlr_ok then SVLR <- SVSTATE
2706 Below is the pseudocode for SVP64 Branches, which is a little less
2707 obvious but identical to the above. The lack of obviousness is down to
2708 the early-exit opportunities.
2710 Effective pseudocode for Horizontal-First Mode:
2713 if (mode_is_64bit) then M <- 0
2715 cond_ok = not SVRMmode.ALL
2716 for srcstep in range(VL):
2717 # select predicate bit or zero/one
2718 if predicate[srcstep]:
2719 # get SVP64 extended CR field 0..127
2720 SVCRf = SVP64EXTRA(BI>>2)
2722 testbit = CRbits[BI & 0b11]
2723 # testbit = CR[BI+32+srcstep*4]
2724 else if not SVRMmode.sz:
2725 # inverted CTR test skip mode
2726 if ¬BO[2] & CTRtest & ¬CTI then
2728 continue # skip to next element
2730 testbit = SVRMmode.SNZ
2731 # actual element test here
2732 ctr_ok <- BO[2] | ((CTR[M:63] != 0) ^ BO[3])
2733 el_cond_ok <- BO[0] | ¬(testbit ^ BO[1])
2734 # check if CTR dec should occur
2736 if CTRtest & (el_cond_ok ^ CTi) then
2738 if ctrdec then CTR <- CTR - 1
2741 cond_ok &= (el_cond_ok & ctr_ok)
2743 cond_ok |= (el_cond_ok & ctr_ok)
2744 # test for VL to be set (and exit)
2745 if VLSET and VSb = (el_cond_ok & ctr_ok) then
2746 if SVRMmode.VLI then SVSTATE.VL = srcstep+1
2747 else SVSTATE.VL = srcstep
2750 if SVRMmode.ALL != (el_cond_ok & ctr_ok):
2752 # SVP64 rules about Scalar registers still apply!
2755 # loop finally done, now test if branch (and update LR)
2757 svlr_ok <- SVRMmode.SL
2759 if AA then NIA <-iea EXTS(BD || 0b00)
2760 else NIA <-iea CIA + EXTS(BD || 0b00)
2761 if SVRMmode.LRu then lr_ok <- ¬lr_ok
2762 if SVRMmode.SLu then svlr_ok <- ¬svlr_ok
2763 if lr_ok then LR <-iea CIA + 4
2764 if svlr_ok then SVLR <- SVSTATE
2767 Pseudocode for Vertical-First Mode:
2770 # get SVP64 extended CR field 0..127
2771 SVCRf = SVP64EXTRA(BI>>2)
2773 # select predicate bit or zero/one
2774 if predicate[srcstep]:
2775 if BRc = 1 then # CR0 vectorised
2776 CR{SVCRf+srcstep} = CRbits
2777 testbit = CRbits[BI & 0b11]
2778 else if not SVRMmode.sz:
2779 # inverted CTR test skip mode
2780 if ¬BO[2] & CTRtest & ¬CTI then
2782 SVSTATE.srcstep = new_srcstep
2783 exit # no branch testing
2785 testbit = SVRMmode.SNZ
2786 # actual element test here
2787 cond_ok <- BO[0] | ¬(testbit ^ BO[1])
2788 # test for VL to be set (and exit)
2789 if VLSET and cond_ok = VSb then
2791 SVSTATE.VL = new_srcstep+1
2793 SVSTATE.VL = new_srcstep
2796 ### Example Shader code
2799 // assume f() g() or h() modify a and/or b
2809 which compiles to something like:
2814 pred loop_pred = a > 2;
2815 // loop continues while any of a elements greater than 2
2816 while(loop_pred.any()) {
2817 // vector of predicate bits
2818 pred if_pred = loop_pred & (b < 5);
2819 // only call f() if at least 1 bit set
2824 // loop mask ANDs with inverted if-test
2825 pred else_pred = loop_pred & ~if_pred;
2826 // only call g() if at least 1 bit set
2827 if(else_pred.any()) {
2834 which will end up as:
2837 # start from while loop test point
2840 sv.cmpi CR80.v, b.v, 5 # vector compare b into CR64 Vector
2841 sv.bc/m=r30/~ALL/sz CR80.v.LT skip_f # skip when none
2842 # only calculate loop_pred & pred_b because needed in f()
2843 sv.crand CR80.v.SO, CR60.v.GT, CR80.V.LT # if = loop & pred_b
2846 # illustrate inversion of pred_b. invert r30, test ALL
2847 # rather than SOME, but masked-out zero test would FAIL,
2848 # therefore masked-out instead is tested against 1 not 0
2849 sv.bc/m=~r30/ALL/SNZ CR80.v.LT skip_g
2850 # else = loop & ~pred_b, need this because used in g()
2851 sv.crternari(A&~B) CR80.v.SO, CR60.v.GT, CR80.V.LT
2854 # conditionally call h(r30) if any loop pred set
2855 sv.bclr/m=r30/~ALL/sz BO[1]=1 h()
2857 sv.cmpi CR60.v a.v, 2 # vector compare a into CR60 vector
2858 sv.crweird r30, CR60.GT # transfer GT vector to r30
2859 sv.bc/m=r30/~ALL/sz BO[1]=1 while_loop
2865 show why LRu would be useful in a loop. Imagine the following
2869 for (int i = 0; i < 8; i++) {
2874 Under these circumstances exiting from the loop is not only based on
2875 CTR it has become conditional on a CR result. Thus it is desirable that
2876 NIA *and* LR only be modified if the conditions are met
2878 v3.0 pseudocode for `bclrl`:
2881 if (mode_is_64bit) then M <- 0
2883 if ¬BO[2] then CTR <- CTR - 1
2884 ctr_ok <- BO[2] | ((CTR[M:63] != 0) ^ BO[3])
2885 cond_ok <- BO[0] | ¬(CR[BI+32] ^ BO[1])
2886 if ctr_ok & cond_ok then NIA <-iea LR[0:61] || 0b00
2887 if LK then LR <-iea CIA + 4
2890 the latter part for SVP64 `bclrl` becomes:
2896 cond_ok <- BO[0] | ¬(CR[BI+32] ^ BO[1])
2898 if ctr_ok & cond_ok then
2899 NIA <-iea LR[0:61] || 0b00
2900 if SVRMmode.LRu then lr_ok <- ¬lr_ok
2901 if lr_ok then LR <-iea CIA + 4
2902 # if NIA modified exit loop
2905 The reason why should be clear from this being a Vector loop:
2906 unconditional destruction of LR when LK=1 makes `sv.bclrl` ineffective,
2907 because the intention going into the loop is that the branch should be to
2908 the copy of LR set at the *start* of the loop, not half way through it.
2909 However if the change to LR only occurs if the branch is taken then it
2910 becomes a useful instruction.
2912 The following pseudocode should **not** be implemented because it
2913 violates the fundamental principle of SVP64 which is that SVP64 looping
2914 is a thin wrapper around Scalar Instructions. The pseducode below is
2915 more an actual Vector ISA Branch and as such is not at all appropriate:
2921 cond_ok <- BO[0] | ¬(CR[BI+32] ^ BO[1])
2922 if ctr_ok & cond_ok then NIA <-iea LR[0:61] || 0b00
2923 # only at the end of looping is LK checked.
2924 # this completely violates the design principle of SVP64
2925 # and would actually need to be a separate (scalar)
2926 # instruction "set LR to CIA+4 but retrospectively"
2927 # which is clearly impossible
2928 if LK then LR <-iea CIA + 4