(no commit message)
[libreriscv.git] / openpower / sv / rfc / ls001.mdwn
1 # OPF ISA WG External RFC LS001 v2 14Sep2022
2
3 * RFC Author: Luke Kenneth Casson Leighton.
4 * RFC Contributors/Ideas: Brad Frey, Paul Mackerras, Konstantinos Magritis,
5 Cesar Strauss, Jacob Lifshay, Toshaan Bharvani, Dimitry Selyutin, Andrey
6 Miroshnikov
7 * Funded by NLnet under the Privacy and Enhanced Trust Programme, EU
8 Horizon2020 Grant 825310
9 * <https://git.openpower.foundation/isa/PowerISA/issues/64>
10 [[ls001/discussion]]
11
12 This proposal is to extend the Power ISA with an Abstract RISC-Paradigm
13 Vectorisation Concept that may be orthogonally applied to **all and any** suitable
14 Scalar instructions, present and future, in the Scalar Power ISA.
15 The Vectorisation System is called
16 ["Simple-V"](https://libre-soc.org/openpower/sv/)
17 and the Prefix Format is called
18 ["SVP64"](https://libre-soc.org/openpower/sv/).
19 **Simple-V is not a Traditional Vector ISA and therefore
20 does not add Vector opcodes or regfiles**.
21 An ISA Concept similar to Simple-V was originally invented in 1994 by
22 Peter Hsu (Architect of the MIPS R8000) but was dropped as MIPS did not
23 have an Out-of-Order Microarchitecture at the time.
24
25 Simple-V is designed for Embedded Scenarios right the way through
26 Audio/Visual DSPs to 3D GPUs and Supercomputing. As it does **not**
27 add actual Vector Instructions, relying solely and exclusively on the
28 **Scalar** ISA, it is **Scalar** instructions that need to be added to
29 the **Scalar** Power ISA before Simple-V may orthogonally Vectorise them.
30
31 The goal of RED Semiconductor Ltd, an OpenPOWER
32 Stakeholder, is to bring to market mass-volume general-purpose compute
33 processors that are competitive in the 3D GPU Audio Visual DSP EDGE IoT
34 desktop chromebook netbook smartphone laptop markets, performance-leveraged
35 by Simple-V. Simple-V thus has to
36 be accompanied by corresponding **Scalar** instructions that bring the
37 **Scalar** Power ISA up-to-date. These include IEEE754
38 [Transcendentals](https://libre-soc.org/openpower/transcendentals/)
39 [AV](https://libre-soc.org/openpower/sv/av_opcodes/)
40 cryptographic
41 [Biginteger](https://libre-soc.org/openpower/sv/biginteger/) and
42 [bitmanipulation](https://libre-soc.org/openpower/sv/bitmanip)
43 operations that ARM
44 Intel AMD and many other ISAs have been adding over the past 12 years
45 and Power ISA has not. Three additional FP-related sets are needed
46 (missing from SFFS) -
47 [int_fp_mv](https://libre-soc.org/openpower/sv/int_fp_mv/)
48 [fclass](https://libre-soc.org/openpower/sv/fclass/) and
49 [fcvt](https://libre-soc.org/openpower/sv/fcvt/)
50 and one set named
51 [crweird](https://libre-soc.org/openpower/sv/cr_int_predication/)
52 increase the capability of CR Fields.
53
54 *Thus it becomes necesary to consider the Architectural Resource
55 Allocation of not just Simple-V but the 80-100 Scalar instructions all
56 at the same time*.
57
58 It is also critical to note that Simple-V **does not modify the Scalar
59 Power ISA**, that **only** Scalar words may be
60 Vectorised, and that Vectorised instructions are **not** permitted to be
61 different from their Scalar words (`addi` must use the same Word encoding
62 as `sv.addi`, and any new Prefixed instruction added **must** also
63 be added as Scalar).
64 The sole semi-exception is Vectorised
65 Branch Conditional, in order to provide the usual Advanced Branching
66 capability present in every Commercial 3D GPU ISA, but it
67 is the *Vectorised* Branch-Conditional that is augmented, not Scalar
68 Branch.
69
70 # Basic principle
71
72 The basic principle of Simple-V is to provide a Precise-Interruptible
73 Zero-Overhead Loop system with associated register "offsetting"
74 which augments a Suffixed instruction as a "template",
75 incrementing the register numbering progressively *and automatically*
76 each time round the "loop". Thus it may be considered to be a form
77 of "Sub-Program-Counter" and at its simplest level can replace a large
78 sequence of regularly-increasing loop-unrolled instructions with just two:
79 one to set the Vector length and one saying where to
80 start from in the regfile.
81
82 On this sound and profoundly simple concept which leverages *Scalar*
83 Micro-architectural capabilities much more comprehensive festures are
84 easy to add, working up towards an ISA that easily matches the capability
85 of powerful 3D GPU Vector Supercomputing ISAs, without ever adding even
86 one single Vector opcode.
87 The inspiration for this came from the fact that on examination of every
88 Vector ISA pseudocode encountered the Vector operations were expressed
89 as a for-loop on a Scalar element
90 operation, and then both a Scalar **and** a Vector instruction was added.
91
92 It felt natural to separate the two at both the ISA and the Hardware Level
93 and thus provide only Scalar instructions (instantly halving the number
94 of instructions), leaving it up to implementors
95 to implement Superscalar and Multi-Issue Micro-architectures at their
96 discretion.
97
98 # Extension Levels
99
100 Simple-V has been subdivided into levels akin to the Power ISA Compliancy
101 Levels. For now let us call them "SV Extension Levels" to differentiate
102 the two. The reason for the
103 [SV Extension Levels](https://libre-soc.org/openpower/sv/compliancy_levels/)
104 is the same as for the
105 Power ISA Compliancy Levels (SFFS, SFS): to not overburden implementors
106 with features that they do not need. *There is no dependence between
107 the two types of Levels*. The resources below therefore are
108 not all required for all SV Extension Levels but they are all required
109 to be reserved.
110
111 # Binary Interoperability
112
113 Power ISA has a reputation as being long-term stable.
114 **Simple-V guarantees binary interoperability** by defining fixed
115 register file bitwidths and size for all instructions.
116 The seduction of permitting different implementors to choose a register file
117 bitwidth and size with the same instructions unfortunately has
118 the catastrophic side-effect of introducing not only binary incompatibility
119 but silent data corruption as well as no means to trap-and-emulate differing
120 bitwidths.[^vsx256]
121
122 Thus "Silicon-Partner" Scalability
123 is prohibited in the Simple-V Scalable Vector ISA,
124 This does
125 mean that `RESERVED` space is crucial to have, in order
126 to safely provide the option of
127 future expanded register file bitwidths and sizes[^msr],
128 under explicitly-distinguishable encoding,
129 **at the discretion of and with the full authority of the OPF ISA WG**,
130 not the implementor ("Silicon Partner").
131
132 # Hardware Implementations
133
134 The fundamental principle of Simple-V is that it sits between Issue and
135 Decode, pausing the Program-Counter to service a "Sub-PC"
136 hardware for-loop. This is very similar to "Zero-Overhead Loops"
137 in High-end DSPs (TI MSP Series).
138
139 Considerable effort has been expended to ensure that Simple-V is
140 practical to implement on an extremely wide range of Industry-wide
141 common **Scalar** micro-architectures. Finite State Machine (for
142 ultra-low-resource and Mission-Critical), In-order single-issue, all the
143 way through to Great-Big Out-of-Order Superscalar Multi-Issue. The
144 SV Extension Levels specifically recognise these differing scenarios.
145
146 SIMD back-end ALUs particularly those with element-level predicate
147 masks may be exploited to good effect with very little additional
148 complexity to achieve high throughput, even on a single-issue in-order
149 microarchitecture. As usually becomes quickly apparent with in-order, its
150 limitations extend also to when Simple-V is deployed, which is why
151 Multi-Issue Out-of-Order is the recommended (but not mandatory) Scalar
152 Micro-architecture.
153
154 The only major concern is in the upper SV Extension Levels: the Hazard
155 Management for increased number of Scalar Registers to 128 (in current
156 versions) but given that IBM POWER9/10 has VSX register numbering 64,
157 and modern GPUs have 128, 256 amd even 512 registers this was deemed
158 acceptable. Strategies do exist in hardware for Hazard Management of
159 such large numbers of registers, even for Multi-Issue microarchitectures.
160
161 # Simple-V Architectural Resources
162
163 * No new Interrupt types are required.
164 * No modifications to existing Power ISA opcodes are required either.
165 * No new Register Files are required (because Simple-V is a category of
166 Zero-Overhead Looping on top of existing instructions and
167 existing registers, not an actual Vector ISA)
168 * GPR FPR and CR Field Register extend to 128. A future
169 version may extend to 256 or beyond[^extend] or also extend VSX[^futurevsx]
170 * 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO)
171 * Another 24-bit (a second 2-bit XO) is needed for a planned future encoding,
172 currently named "SVP64-Single"[^likeext001]
173 * A third 24-bits (third 2-bit XO) is strongly recommended to be `RESERVED`
174 such that future unforeseen capability is needed (although this may be
175 alternatively achieved with a mandatory PCR or MSR bit)
176 * To hold all Vector Context, five SPRs are needed for userspace.
177 If Supervisor and Hypervisor mode are to
178 also support Simple-V they will correspondingly need five SPRs each.
179 (Some 32/32-to-64 aliases are advantageous but not critical).
180 * Five 6-bit XO (A-Form) "Management" instructions are needed. These are
181 Scalar 32-bit instructions and *may* be 64-bit-extended in future
182 (safely within the SVP64 space: no need for an EXT001 encoding).
183
184 **Summary of Simple-V Opcode space**
185
186 * 75% of one Major Opcode (equivalent to the rest of EXT017)
187 * Five 6-bit XO 32-bit operations.
188
189 No further opcode space *for Simple-V* is envisaged to be required for
190 at least the next decade (including if added on VSX)
191
192 **Simple-V SPRs**
193
194 * **SVSTATE** - Vectorisation State sufficient for Precise-Interrupt
195 Context-switching and no adverse latency.
196 * **SVSRR0** - identical in purpose to SRR0/1: storing SVSTATE on context-switch
197 along-side MSR and PC.
198 * **SVSHAPE0-3** - these are 32-bit and may be grouped in pairs, they REMAP
199 (shape) the Vectors
200 * **SVLR** - again similar to LR for exactly the same purpose, SVSTATE
201 is swapped with SVLR by SV-Branch-Conditional for exactly the same
202 reason that NIA is swapped with LR
203
204 **Vector Management Instructions**
205
206 These fit into QTY 5of 6-bit XO 32-bit encoding (svshape and svshape2 share
207 the same space):
208
209 * **setvl** - Cray-style Scalar Vector Length instruction
210 * **svstep** - used for Vertical-First Mode and for enquiring about internal
211 state
212 * **svremap** - "tags" registers for activating REMAP
213 * **svshape** - convenience instruction for quickly setting up Matrix, DCT,
214 FFT and Parallel Reduction REMAP
215 * **svshape2** - additional convenience instruction to set up "Offset" REMAP
216 (fits within svshape's XO encoding)
217 * **svindex** - convenience instruction for setting up "Indexed" REMAP.
218
219 # SVP64 24-bit Prefixes
220
221 The SVP64 24-bit Prefix (RM) provides several options,
222 all fitting within the 24-bit space (and no other).
223 These Modes do not interact with SVSTATE per se. SVSTATE
224 primarily controls the looping (quantity, order), RM
225 influences the *elements* (the Suffix). There is however
226 some close interaction when it comes to predication.
227 REMAP is separately
228 outlined in another section.
229
230 The primary options all of which are aimed at reducing instruction
231 count and reducing assembler complexity are:
232
233 * element-width overrides, which dynamically redefine each SFFS or SFS
234 Scalar prefixed instruction to be 8-bit, 16-bit, 32-bit or 64-bit
235 operands **without requiring new 8/16/32 instructions.**[^pseudorewrite]
236 This results in full BF16 and FP16 opcodes being added to the Power ISA
237 **without adding BF16 or FP16 opcodes** including full conversion
238 between all formats.
239 * predication. this is an absolutely essential feature for a 3D GPU VPU ISA.
240 CR Fields are available as Predicate Masks hence the reason for their
241 extension to 128. Twin-Predication is also provided: this may best
242 be envisaged as back-to-back VGATHER-VSCATTER but is not restricted
243 to LD/ST, its use saves on instruction count. Enabling one or other
244 of the predicates provides all of the other types of operations
245 found in Vector ISAs (VEXTRACT, VINSERT etc) again with no need
246 to actually provide explicit such instructions.
247 * Saturation. **all** LD/ST and Arithmetic and Logical operations may
248 be saturated (without adding explicit scalar saturated opcodes)
249 * Reduction and Prefix-Sum (Fibonnacci Series) Modes
250 * vec2/3/4 "Packing" and "Unpacking" (similar to VSX `vpack` and `vpkss`)
251 accessible in a way that is easier than REMAP, added for the same reasons
252 that drove `vpack` and `vpkss` etc. to be added: pixel, audio, and 3D
253 data manipulation. With Pack/Unpack being part of SVSTATE it can be
254 applied *in-place* saving register file space (no copy/mv needed).
255 * Load/Store speculative "fault-first" behaviour, identical to SVE and RVV
256 Fault-first: provides auto-truncation of a speculative sequential parallel
257 LD/ST batch, helping
258 solve the "SIMD Considered Harmful" stripmining problem from a Memory
259 Access perspective.
260 * Data-Dependent Fail-First: a 100% Deterministic extension of the LDST
261 ffirst concept: first `Rc=1 BO test` failure terminates looping and
262 truncates VL to that exact point. Useful for implementing algorithms
263 such as `strcpy` in around 14 high-performance Vector instructions, the
264 option exists to include or exclude the failing element.
265 * Predicate-result: a strategic mode that effectively turns all and any
266 operations into a type of `cmp`. An `Rc=1 BO test` is performed and if
267 failing that element result is **not** written to the regfile. The `Rc=1`
268 Vector of co-results **is** always written (subject to usual predication).
269 Termed "predicate-result" because the combination of producing then
270 testing a result is as if the test was in a follow-up predicated
271 copy/mv operation, it reduces regfile pressure and instruction count.
272 Also useful on saturated or other overflowing operations, the overflowing
273 elements may be excluded from outputting to the regfile then
274 post-analysed outside of critical hot-loops.
275
276 **RM Modes**
277
278 There are five primary categories of instructions in Power ISA, each of
279 which needed slightly different Modes. For example, saturation and
280 element-width overrides are meaningless to Condition Register Field
281 operations, and Reduction is meaningless to LD/ST but Saturation
282 saves register file ports in critical hot-loops. Thus the 24 bits may
283 be suitably adapted to each category.
284
285 * Normal - arithmetic and logical including IEEE754 FP
286 * LD/ST immediate - includes element-strided and unit-strided
287 * LD/ST indexed
288 * CR Field ops
289 * Branch-Conditional - saves on instruction count in 3D parallel if/else
290
291 It does have to be pointed out that there is huge pressure on the
292 Mode bits. There was therefore insufficient room, unlike the way that
293 EXT001 was designed, to provide "identifying bits" *without first partially
294 decoding the Suffix*. This should in no way be conflated with or taken
295 as an indicator that changing the meaning of the Suffix is performed
296 or desirable.
297
298 Some considerable care has been taken to ensure that Decoding may be
299 performed in a strict forward-pipelined fashion that, aside from changes in
300 SVSTATE (necessarily cached and propagated alongside MSR and PC)
301 and aside from the initial 32/64 length detection (also kept simple),
302 a Multi-Issue Engine would have no difficulty (performance maximisable).
303 With the initial partial RM Mode type-identification
304 decode performed above the Vector operations may then
305 easily be passed downstream in a fully forward-progressive piplined fashion
306 to independent parallel units for further analysis.
307
308 **Vectorised Branch-Conditional**
309
310 As mentioned in the introduction this is the one sole instruction group
311 that
312 is different pseudocode from its scalar equivalent. However even there
313 its various Mode bits and options can be set such that in the degenerate
314 case the behaviour becomes identical to Scalar Branch-Conditional.
315
316 The two additional Modes within Vectorised Branch-Conditional, both of
317 which may be combined, are `CTR-Mode` and `VLI-Test` (aka "Data Fail First").
318 CTR Mode extends the way that CTR may be decremented unconditionally
319 within Scalar Branch-Conditional, and not only makes it conditional but
320 also interacts with predication. VLI-Test provides the same option
321 as Data-Dependent Fault-First to Deterministically truncate the Vector
322 Length at the fail **or success** point.
323
324 Boolean Logic rules on sets (treating the Vector of CR Fields to be tested by
325 `BO` as a set) dictate that the Branch should take place on either 'ALL'
326 tests succeeding (or failing) or whether 'SOME' tests succeed (or fail).
327 These options provide the ability to cover the majority of Parallel
328 3D GPU Conditions, saving a not inconsiderable number of instructions
329 especially given the close interaction with CTR in hot-loops.
330
331 Also `SVLR` is introduced, which is a parallel twin of `LR`, and saving
332 and restoring of LR and SVLR may be deferred until the final decision
333 as to whether to branch. In this way `sv.bclrl` does not corrupt `LR`.
334
335 Vectorised Branch-Conditional due to its side-effects (e.g. reducing CTR
336 or truncating VL) has practical uses even if the Branch is deliberately
337 set to the next instruction (CIA+8). For example it may be used to reduce
338 CTR by the number of bits set in a GPR, if that GPR is given as the predicate
339 mask `sv.bc/pm=r3`.
340
341 # SVP64Single 24-bits
342
343 The `SVP64-Single` 24-bit encoding focusses primarily on ensuring that
344 all 128 Scalar registers are fully accessible, provides element-width
345 overrides, one-bit predication
346 and brings Saturation to all existing Scalar operations.
347 BF16 and FP16 are thus
348 provided in the Scalar Power ISA without one single explicit FP16 or BF16
349 32-bit opcode being added. The downside: such Scalar operations are
350 all 64-bit encodings.
351
352 As SVP64Single is new and still under development, space for it may
353 instead be `RESERVED`. It is however necessary in *some* form
354 as there are limitations
355 in SVP64 Register numbering, particularly for 4-operand instructions,
356 that can only be easily overcome by SVP64Single.
357
358 # Vertical-First Mode
359
360 This is a Computer Science term that needed first to be invented.
361 There exists only one other Vertical-First Vector ISA in the world:
362 Mitch Alsup's VVM Extension for the 66000, details of which may be
363 obtained publicly on `comp.arch` or directly from Mitch Alsup under
364 NDA. Several people have
365 independently derived Vertical-First: it simply did not have a
366 Computer Science term associated with it.
367
368 If we envisage register and Memory layout to be Horizontal and
369 instructions to be Vertical, and to then have some form of Loop
370 System (wherther Zero-Overhead or just branch-conditional based)
371 it is easier to then conceptualise VF vs HF Mode:
372
373 * Vertical-First progresses through *instructions* first before
374 moving on to the next *register* (or Memory-address in the case
375 of Mitch Alsup's VVM).
376 * Horizontal-First (also known as Cray-style Vectors) progresses
377 through **registers** (or, register *elements* in traditional
378 Cray-Vector ISAs) in full before moving on to the next *instruction*.
379
380 Mitch Alsup's VVM Extension is a form of hardware-level auto-vectorisation
381 based around Zero-Overhead Loops. Using a Variable-Length Encoding all
382 loop-invariant registers are "tagged" such that the Hazard Management
383 Engine may perform optimally and do less work in automatically identifying
384 parallelism opportunities.
385 With it not being appropriate to use Variable-Length Encoding in the Power
386 ISA a different much more explicit strategy was taken in Simple-V.
387
388 The biggest advantage inherent in Vertical-First is that it is very easy
389 to introduce into compilers, because all looping, as far as programs
390 is concerned, remains expressed as *Scalar assembler*.[^autovec]
391 Whilst Mitch Alsup's
392 VVM biggest strength is its hardware-level auto-vectorisation
393 but is limited in its ability to call
394 functions, Simple-V's Vertical-First provides explicit control over the
395 parallelism ("hphint")[^hphint] and also allows for full state to be stored/restored
396 (SVLR combined with LR), permitting full function calls to be made
397 from inside Vertical-First Loops, and potentially allows arbitrarily-depth
398 nested VF Loops.
399
400 Simple-V Vertical-First Looping requires an explicit instruction to
401 move `SVSTATE` regfile offsets forward: `svstep`. An early version of
402 Vectorised
403 Branch-Conditional attempted to merge the functionality of `svstep`
404 into `sv.bc`: it became CISC-like in its complexity and was quickly reverted.
405
406 # Simple-V REMAP subsystem
407
408 [REMAP](https://libre-soc.org/openpower/sv/remap)
409 is extremely advanced but brings features already present in other
410 DSPs and Supercomputing ISAs. Normally (without these features)
411 algorithms are are costly or
412 convoluted to implement. They are typically implemented
413 as hard-coded fully loop-unrolled assembler which is often
414 auto-generated by specialist dedicated tools, or written
415 entirely by hand.
416 All REMAP Schedules *including Indexed*
417 are 100% Deterministic from their point of declaration,
418 making it possible to forward-plan
419 Issue, Memory access and Register Hazard Management
420 in Multi-Issue Micro-architectures.
421 If combined with Vertical-First then much more complex operations may exploit
422 REMAP Schedules, such as Complex Number FFTs.
423
424 * **DCT/FFT** REMAP brings more capability than TI's MSP-Series DSPs and
425 Qualcom Hexagon DSPs, and is not restricted to Integer or FP.
426 (Galois Field is possible, implementing NTT). Operates *in-place*
427 significantly reducing register usage.
428 * **Matrix** REMAP brings more capability than any other Matrix Extension
429 (AMD GPUs, Intel, ARM), not being restricted to Power-2 sizes. Also not
430 limited to the type of operation, it may perform Warshall Transitive
431 Closure, Integer Matrix, Bitmanipulation Matrix, Galois Field (carryless
432 mul) Matrix, and with care potentially Graph Maximum Flow as well. Also
433 suited to Convolutions, Matrix Transpose and rotate, *all* of which is
434 in-place.
435 * **General-purpose Indexed** REMAP, this option is provided to implement
436 an equivalent of VSX `vperm`, as a general-purpose catch-all means of
437 covering algorithms outside of the other REMAP Engines.
438 * **Parallel Reduction** REMAP, performs an automatic map-reduce using
439 *any suitable scalar operation*.
440
441 \newpage{}
442 # Scalar Operations
443
444 The primary reason for mentioning the additional Scalar operations
445 is because they are so numerous, with Power ISA not having advanced
446 in the *general purpose* compute area in the past 12 years, that some
447 considerable care is needed.
448
449 Summary:
450 **Including Simple-V, to fit everything at least 75% of 3 separate
451 Major Opcodes would be required**
452
453 Candidates (for all but the X-Form instructions) include:
454
455 * EXT006 (80% free)
456 * EXT017 (75% free but not recommended)
457 * EXT001 (50% free)
458 * EXT009 (100% free)
459 * EXT005 (100% free)
460 * brownfield space in EXT019 (25% but NOT recommended)
461
462 SVP64, SVP64-Single and SVP64-Reserved would require on their own each 25%
463 of one Major Opcode for a total of 75% of one Major Opcode. The remaining
464 **Scalar** opcodes, due to there being two separate sets of operations
465 with 16-bit immediates, will require the other space totalling two 75%
466 Majors.
467
468 Note critically that:
469
470 * Unlike EXT001, SVP64's 24-bits may **not** hold also any Scalar
471 operations. There is no free available space: a 25th bit would
472 be required. The entire 24-bits is **required** for the abstracted
473 Hardware-Looping Concept **even when these 24-bits are zero**
474 * Any Scalar 64-bit instruction (regardless of how it is encoded) is unsafe to
475 then Vectorise because this creates the situation of Prefixed-Prefixed,
476 resulting in deep complexity in Hardware Decode at a critical juncture, as
477 well as introducing 96-bit instructions.
478 * **All** of these Scalar instructions are candidates for Vectorisation.
479 Thus none of them may be 64-bit-Scalar-only.
480
481 **Minor Opcodes to fit candidates above**
482
483 In order of size, for bitmanip and A/V DSP purposes:
484
485 * QTY 3of 2-bit XO: ternlogi, crternlogi, grevlogi
486 * QTY 7of 3-bit XO: xpermi, binlut, grevlog, swizzle-mv/fmv, bitmask, bmrevi
487 * QTY 8of 5/6-bit (A-Form): xpermi, bincrflut, bmask, fmvis, fishmv, bmrev,
488 Galois Field
489 * QTY 30of 10-bit (X-Form): cldiv/mul, av-min/max/diff, absdac, xperm etc.
490 (easily fit EXT019, EXT031).
491
492 Note: Some of the Galois Field operations will require QTY 1of Polynomial
493 SPR (per userspace supervisor hypervisor).
494
495 **EXT004**
496
497 For biginteger math, two instructions in the same space as "madd" are to
498 be proposed. They are both 3-in 2-out operations taking or producing a
499 64-bit "pair" (like RTp), and perform 128/64 mul and div/mod operations
500 respectively. These are **not** the same as VSX operations which are
501 128/128, and they are **not** the same as existing Scalar mul/div/mod,
502 all of which are 64/64 (or 64/32).
503
504 **EXT059 and EXT063**
505
506 Additionally for High-Performance Compute and Competitive 3D GPU, IEEE754 FP
507 Transcendentals are required, as are some DCT/FFT "Twin-Butterfly" operations.
508 For each of EXT059 and EXT063:
509
510 * QTY 33of X-Form "1-argument" (fsin, fsins, fcos, fcoss)
511 * QTY 15of X-Form "2-argument" (pow, atan2, fhypot)
512 * QTY 5of A-Form "3-in 2-out" FP Butterfly operations for DCT/FFT
513 * QTY 8of X-Form "2-in 2-out" FP Butterfly operations (again for DCT/FFT)
514 * An additional 16 instructions for IEEE754-2019
515 (fminss/fmaxss, fminmag/fmaxmag)
516 [under evaluation](https://bugs.libre-soc.org/show_bug.cgi?id=923)
517 as of 08Sep2022
518
519 # Adding new opcodes.
520
521 With Simple-V being a type of Zero-Overhead Loop Engine on top of
522 Scalar operations some clear guidelines are needed on how both
523 existing "Defined Words" (Public v3.1 Section 1.6.3 term) and future
524 Scalar operations are added within the 64-bit space. Examples of
525 legal and illegal allocations are given later.
526
527 The primary point is that once an instruction is defined in Scalar
528 32-bit form its corresponding space **must** be reserved in the
529 SVP64 area with the exact same 32-bit form, even if that instruction
530 is "Unvectoriseable" (`sc`, `sync`, `rfid` and `mtspr` for example).
531 Instructions may **not** be added in the Vector space without also
532 being added in the Scalar space, and vice-versa, *even if Unvectoriseable*.
533
534 This is extremely important because the worst possible situation
535 is if a conflicting Scalar instruction is added by another Stakeholder,
536 which then turns out to be Vectoriseable: it would then have to be
537 added to the Vector Space with a *completely different Defined Word*
538 and things go rapidly downhill in the Decode Phase from there.
539 Setting a simple inviolate rule helps avoid this scenario but does
540 need to be borne in mind when discussing potential allocation
541 schemes, as well as when new Vectoriseable Opcodes are proposed
542 for addition by future RFCs: the opcodes **must** be uniformly
543 added to Scalar **and** Vector spaces.
544
545 \newpage{}
546 # Potential Opcode allocation solution
547
548 There are unfortunately some inviolate requirements that directly place
549 pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that
550 it risks jeapordising the Power ISA. These requirements are:
551
552 * all of the scalar operations must be Vectoriseable
553 * all of the scalar operations intended for Vectorisation
554 must be in a 32-bit encoding (not prefixed-prefixed to 96-bit)
555 * bringing Scalar Power ISA up-to-date from the past 12 years
556 needs 75% of two Major opcodes all on its own
557
558 There exists a potential scheme which meets (exceeds) the above criteria,
559 providing plenty of room for both Scalar (and Vectorised) operations,
560 *and* provides SVP64-Single with room to grow. It
561 is based loosely around Public v3.1 EXT001 Encoding.[^ext001]
562
563 | 0-5 | 6 | 7 | 8-31 | Description |
564 |-----|---|---|-------|---------------------------|
565 | PO | 0 | 0 | 0000 | new-suffix `RESERVED1` |
566 | PO | 0 | 0 | !zero | new-suffix, scalar (SVP64Single), or `RESERVED3` |
567 | PO | 1 | 0 | 0000 | new scalar-only word, or `RESERVED2` |
568 | PO | 1 | 0 | !zero | old-suffix, scalar (SVP64Single), or `RESERVED4` |
569 | PO | 0 | 1 | nnnn | new-suffix, vector (SVP64) |
570 | PO | 1 | 1 | nnnn | old-suffix, vector (SVP64) |
571
572 * **PO** - Primary Opcode. Likely candidates: EXT005, EXT009
573 * **bit 6** - specifies whether the suffix is old (EXT000-EXT063)
574 or new (EXTn00-EXTn63, n greater than 1)
575 * **bit 7** - defines whether the Suffix is Scalar-Prefixed or Vector-Prefixed
576 (caveat: see bits 8-31)
577 * **old-suffix** - the EXT000 to EXT063 32-bit Major opcodes of Power ISA 3.0
578 * **new scalar-only** - a **new** Major Opcode area **exclusively**
579 for Scalar-only instructions that shall **never** be Prefixed by SVP64
580 (RESERVED2 EXT300-EXT363)
581 * **new-suffix** - a **new** Major Opcode area (RESERVED1 EXT200-EXT263)
582 that **may** be Prefixed by SVP64 and SVP64Single
583 * **0000** - all 24 bits bits 8-31 are zero (0x000000)
584 * **!zero** - bits 8-31 may be any value *other* than zero (0x000001-0xffffff)
585 * **nnnn** - bits 8-31 may be any value in the range 0x000000 to 0xffffff
586 * **SVP64Single** - a ([TBD](https://bugs.libre-soc.org/show_bug.cgi?id=905))
587 *Scalar* Encoding that is near-identical to SVP64
588 except that it is equivalent to hard-coded VL=1
589 at all times. Predication is permitted, Element-width-overrides is
590 permitted, Saturation is permitted.
591 If not allocated within the scope of this RFC
592 then these are requested to be `RESERVED` for a future Simple-V
593 proposal.
594 * **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorisation
595 Augmentation of suffixes.
596
597 For the needs identified by Libre-SOC (75% of 2 POs),
598 `RESERVED1` space *needs*
599 allocation to new POs, `RESERVED2` does not.[^only2]
600
601 | | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1) |
602 |----------|---------------------------|---------------------------|------------------|
603 |new bit6=0| `RESERVED1`:{EXT200-263} | `RESERVED3`:SVP64-Single:{EXT200-263} | SVP64:{EXT200-263} |
604 |old bit6=1| `RESERVED2`:{EXT300-363} | `RESERVED4`:SVP64-Single:{EXT000-063} | SVP64:{EXT000-063} |
605
606 * **`RESERVED2`:{EXT300-363}** (not strictly necessary to be added) is not
607 and **cannot** ever be Vectorised or Augmented by Simple-V or any future
608 Simple-V Scheme.
609 it is a pure **Scalar-only** word-length PO Group. It may remain `RESERVED`.
610 * **`RESERVED1`:{EXT200-263}** is also a new set of 64 word-length Major
611 Opcodes.
612 These opcodes do not *need* to be Simple-V-Augmented
613 *but the option to do so exists* should an Implementor choose to do so.
614 This is unlike `EXT300-363` which may **never** be Simple-V-Augmented
615 under any circumstances.
616 * **RESERVED3:`SVP64-Single:{EXT200-263}`** - Major opcodes 200-263 with
617 Single-Augmentation, providing a one-bit predicate mask, element-width
618 overrides on source and destination, and the option to extend the Scalar
619 Register numbering (r0-32 extends to r0-127). **Placing of alternative
620 instruction encodings other than those exactly defined in EXT200-263
621 is prohibited**.
622 * **RESERVED4:`SVP64-Single:{EXT000-063}`** - Major opcodes 000-063 with
623 Single-Augmentation, just like SVP64-Single on EXT200-263, these are
624 in effect Single-Augmented-Prefixed variants of the v3.0 32-bit Power ISA.
625 Alternative instruction encodings other than the exact same 32-bit word
626 from EXT000-EXT063 are likewise prohibited.
627 * **`SVP64:{EXT000-063}`** and **`SVP64:{EXT200-263}`** - Full Vectorisation
628 of EXT000-063 and EXT200-263 respectively, these Prefixed instructions
629 are likewise prohibited from being a different encoding from their
630 32-bit scalar versions.
631
632 Limitations of this scheme is that new 32-bit Scalar operations have to have
633 a 32-bit "prefix pattern" in front of them. If commonly-used this could
634 increase binary size. Thus the Encodings EXT300-363 and EXT200-263 should
635 only be allocated for less-popular operations. However the scheme does
636 have the strong advantage of *tripling* the available number of Major
637 Opcodes in the Power ISA, caveat being that care on allocation is needed
638 because EXT200-EXT263 may be SVP64-Augmented whilst EXT300-EXT363 may **not**.
639 The issues of allocation for bitmanip etc. from Libre-SOC is therefore
640 overwhelmingly made moot. The only downside is that there is no
641 `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR).
642
643 # Potential Opcode allocation solution (2)
644
645 One of the risks of the bit 6/7 scheme above is that there is no
646 room to share PO9 (EXT009) with other potential uses. A workaround for
647 that is as follows:
648
649 * EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit
650 encoding
651 * bit 6 if 0b1 is 100% for Simple-V augmentation (Public v3.1 1.6.3)
652 "Defined Word" (aka EXT000-063), with the exception of 0x24000000
653 as a Prefix, which is a new RESERVED encoding.
654 * when bit 6 is 0b0 and bits 32-33 are 0b11 are **defined** as also
655 allocated to Simple-V
656 * all other patterns are `RESERVED` for other purposes,
657
658 | 0-5 | 6 | 7 | 8-31 | 32:33 | Description |
659 |-----|---|---|-------|-------|---------------------------|
660 | PO9?| 0 | 0 | 0000 | xx | RESERVED (other) |
661 | PO9?| 0 | 0 | !zero | 11 | SVP64 (current and future) |
662 | PO9?| 0 | 0 | !zero | 00-10 | RESERVED (other) |
663 | PO9?| 0 | 1 | xxxx | 11 | SVP64 (current and future) |
664 | PO9?| 0 | x | xxxx | 00-10 | RESERVED (other) |
665 | PO9?| 1 | x | xxxx | xx | SVP64 (current and future) |
666
667 This ensures that any potential for future conflict over uses of the
668 EXT009 space, jeapordising Simple-V in the process, are avoided.
669
670 SVP64 then becomes:
671
672 | 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
673 |-----|---|---|-------|------|---------------------------|
674 | PO | 0 | 0 | !zero | 0b11 | SVP64Single:EXT248-263, or `RESERVED3` |
675 | PO | 0 | 0 | 0000 | 0b11 | Scalar EXT248-263 |
676 | PO | 0 | 1 | nnnn | 0b11 | SVP64:EXT248-263 |
677 | PO | 1 | 0 | !zero | nn | SVP64Single:EXT000-063 or `RESERVED4` |
678 | PO | 1 | 1 | nnnn | nn | SVP64:EXT000-063 |
679
680 and reserved areas, QTY 1of 30-bit and QTY 3of 55-bit, are:
681
682 | 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
683 |-----|---|---|-------|------|---------------------------|
684 | PO | 0 | 0 | 0000 | 0b11 | `RESERVED1` or EXT300-363 |
685 | PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 |
686 | PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 |
687 | PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 |
688
689 with additional potentially QTY 3of 30-bit reserved areas
690 (part of Scalar Unvectoriseable EXT200-247):
691
692 | 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
693 |-----|---|---|-------|------|---------------------------|
694 | PO9?| 1 | 0 | 0000 | 0b01 | RESERVED (other) |
695 | PO9?| 1 | 0 | 0000 | 0b10 | RESERVED (other) |
696 | PO9?| 1 | 0 | 0000 | 0b11 | RESERVED (other) |
697
698 Where:
699
700 * SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
701 (but needs reserving as part of this RFC)
702 * `RESERVED1/2` is available for new general-purpose **never**-Simple-V
703 (non-Vectoriseable) 32-bit encodings
704 * EXT248-263 is for "new" instructions
705 which **must** also simultaneously request the corresponding space
706 in SVP64, even if the instruction is non-Vectoriseable.
707 * Anything Vectorised-EXT000-063 is **automatically** being
708 requested as 100% Reserved for every single "Defined Word"
709 (Public v3.1 1.6.3 definition). Vectorised-EXT001 is defined as illegal.
710 * Any **future** instruction
711 added to EXT000-063 likewise, is **automatically**
712 assigned corresponding reservations in the SVP64:EXT000-063
713 and SVP64Single:EXT000-063 area, regardless of whether the
714 instruction is Vectoriseable or not.
715
716 Bit-allocation Summary:
717
718 * EXT3nn and three other encodings provide space for non-Simple-V
719 operations to have QTY 4of EXTn00-EXTn47 Primary Opcode ranges
720 * QTY 3of 55-bit spaces also exist for future use (longer by 3 bits
721 than opcodes allocated in EXT001)
722 * Simple-V EXT2nn is restricted to range EXT248-263
723 * non-Simple-V EXT2nn is restricted to range EXT200-247
724 * Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
725 * The clear separation between Simple-V and non-Simple-V means there is
726 no possibility of future RFCs encroaching on the others' space.
727
728 \newpage{}
729
730 **EXT000-EXT063**
731
732 These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document
733 Power ISA v3.1 Section 1.6.3 Book I calls it a "defined word".
734
735 | 0-5 | 6-31 |
736 |--------|--------|
737 | PO | EXT000-063 Scalar (v3.0 or v3.1) operation |
738
739 **SVP64Single:{EXT000-063}** bit6=old bit7=scalar
740
741 This encoding, identical to SVP64Single:{EXT200-263},
742 introduces SVP64Single Augmentation of v3.0 Scalar word instructions.
743 All meanings must be identical to EXT000 to EXT063, and is is likewise
744 prohibited to add an instruction in this area without also adding
745 the exact same (non-Augmented) instruction in EXT000-063 with the
746 exact same Scalar word.
747 PO2 is in the range 0b00000 to 0b11111 to represent EXT000-063 respectively.
748 Augmenting EXT001 is prohibited.
749
750 | 0-5 | 6 | 7 | 8-31 | 32-63 |
751 |--------|---|---|-------|---------|
752 | PO (9)?| 1 | 0 | !zero | SVP64Single:{EXT000-063} |
753
754 **SVP64:{EXT000-063}** bit6=old bit7=vector
755
756 This encoding is identical to **SVP64:{EXT200-263}** except it
757 is the Vectorisation of existing v3.0/3.1 Scalar-words, EXT000-063.
758 All the same rules apply with the addition that
759 Vectorisation of EXT001 is prohibited.
760
761 | 0-5 | 6 | 7 | 8-31 | 32-63 |
762 |--------|---|---|-------|---------|
763 | PO (9)?| 1 | 1 | nnnn | SVP64:{EXT000-063} |
764
765 **{EXT248-263}** bit6=new bit7=scalar
766
767 This encoding represents the opportunity to introduce EXT248-263.
768 It is a Scalar-word encoding, and does not require implementing
769 SVP64 or SVP64-Single, but does require the Vector-space to be allocated.
770 PO2 is in the range 0b11000 to 0b111111 to represent EXT248-263 respectively.
771
772 | 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
773 |--------|---|---|-------|------|---------|---------|
774 | PO (9)?| 0 | 0 | 0000 | 0b11 |PO2[2:5] | {EXT248-263} |
775
776 **SVP64Single:{EXT248-263}** bit6=new bit7=scalar
777
778 This encoding, which is effectively "implicit VL=1"
779 and comprising (from bits 8-31)
780 *at least some* form of Augmentation, it represents the opportunity
781 to Augment EXT248-263 with the SVP64Single capabilities.
782 Must be allocated under Scalar *and* SVP64 simultaneously.
783
784 | 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
785 |--------|---|---|-------|------|---------|---------|
786 | PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT248-263} |
787
788 **SVP64:{EXT248-263}** bit6=new bit7=vector
789
790 This encoding, which permits VL to be dynamic (settable from GPR or CTR)
791 is the Vectorisation of EXT248-263.
792 Instructions may not be placed in this category without also being
793 implemented as pure Scalar *and* SVP64Single. Unlike SVP64Single
794 however, there is **no reserved encoding** (bits 8-24 zero).
795 VL=1 may occur dynamically
796 at runtime, even when bits 8-31 are zero.
797
798 | 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
799 |--------|---|---|-------|------|---------|---------|
800 | PO (9)?| 0 | 1 | nnnn | 0b11 |PO2[2:5] | SVP64:{EXT248-263} |
801
802 **RESERVED2 / EXT300-363** bit6=old bit7=scalar
803
804 This is entirely at the discretion of the ISA WG. Libre-SOC is *not*
805 proposing the addition of EXT300-363: it is merely a possibility for
806 future. The reason the space is not needed is because this is within
807 the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix
808 area being all-zero (bits 8-31) this is defined as "having no augmentation"
809 (in the Simple-V Specification it is termed `Scalar Identity Behaviour`).
810 This in turn makes this prefix a *degenerate duplicate* so may be allocated
811 for other purposes.
812
813 | 0-5 | 6 | 7 | 8-31 | 32-63 |
814 |--------|---|---|-------|---------|
815 | PO (9)?| 1 | 0 | 0000 | EXT300-363 or `RESERVED1` |
816
817 \newpage{}
818 # Example Legal Encodings and RESERVED spaces
819
820 This section illustrates what is legal encoding, what is not, and
821 why the 4 spaces should be `RESERVED` even if not allocated as part
822 of this RFC.
823
824 **legal, scalar and vector**
825
826 | width | assembler | prefix? | suffix | description |
827 |-------|-----------|--------------|-----------|---------------|
828 | 32bit | fishmv | none | 0x12345678| scalar EXT0nn |
829 | 64bit | ss.fishmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
830 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
831
832 OR:
833
834 | width | assembler | prefix? | suffix | description |
835 |-------|-----------|--------------|-----------|---------------|
836 | 64bit | fishmv | 0x24000000 | 0x12345678| scalar EXT2nn |
837 | 64bit | ss.fishmv | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
838 | 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
839
840 Here the encodings are the same, 0x12345678 means the same thing in
841 all cases. Anything other than this risks either damage (truncation
842 of capabilities of Simple-V) or far greater complexity in the
843 Decode Phase.
844
845 This drives the compromise proposal (above) to reserve certain
846 EXT2nn POs right
847 across the board
848 (in the Scalar Suffix side, irrespective of Prefix), some allocated
849 to Simple-V, some not.
850
851 **illegal due to missing**
852
853 | width | assembler | prefix? | suffix | description |
854 |-------|-----------|--------------|-----------|---------------|
855 | 32bit | fishmv | none | 0x12345678| scalar EXT0nn |
856 | 64bit | ss.fishmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
857 | 64bit | unallocated | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
858
859 This is illegal because the instruction is possible to Vectorise,
860 therefore it should be **defined** as Vectoriseable.
861
862 **illegal due to unvectoriseable**
863
864 | width | assembler | prefix? | suffix | description |
865 |-------|-----------|--------------|-----------|---------------|
866 | 32bit | mtmsr | none | 0x12345678| scalar EXT0nn |
867 | 64bit | ss.mtmsr | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
868 | 64bit | sv.mtmsr | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
869
870 This is illegal because the instruction `mtmsr` is not possible to Vectorise,
871 at all. This does **not** convey an opportunity to allocate the
872 space to an alternative instruction.
873
874 **illegal unvectoriseable in EXT2nn**
875
876 | width | assembler | prefix? | suffix | description |
877 |-------|-----------|--------------|-----------|---------------|
878 | 64bit | mtmsr2 | 0x24000000 | 0x12345678| scalar EXT2nn |
879 | 64bit | ss.mtmsr2 | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
880 | 64bit | sv.mtmsr2 | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
881
882 For a given hypothetical `mtmsr2` which is inherently Unvectoriseable
883 whilst it may be put into the scalar EXT2nn space it may **not** be
884 allocated in the Vector space. As with Unvectoriseable EXT0nn opcodes
885 this does not convey the right to use the 0x24/0x26 space for alternative
886 opcodes. This hypothetical Unvectoriseable operation would be better off
887 being allocated as EXT001 Prefixed, EXT000-063, or hypothetically in
888 EXT300-363.
889
890 **ILLEGAL: dual allocation**
891
892 | width | assembler | prefix? | suffix | description |
893 |-------|-----------|--------------|-----------|---------------|
894 | 32bit | fredmv | none | 0x12345678| scalar EXT0nn |
895 | 64bit | ss.fredmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
896 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
897
898 the use of 0x12345678 for fredmv in scalar but fishmv in Vector is
899 illegal. the suffix in both 64-bit locations
900 must be allocated to a Vectoriseable EXT000-063
901 "Defined Word" (Public v3.1 Section 1.6.3 definition)
902 or not at all.
903
904 **illegal unallocated scalar EXT0nn or EXT2nn:**
905
906 | width | assembler | prefix? | suffix | description |
907 |-------|-----------|--------------|-----------|---------------|
908 | 32bit | unallocated | none | 0x12345678| scalar EXT0nn |
909 | 64bit | ss.fredmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
910 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
911
912 and:
913
914 | width | assembler | prefix? | suffix | description |
915 |-------|-----------|--------------|-----------|---------------|
916 | 64bit | unallocated | 0x24000000 | 0x12345678| scalar EXT2nn |
917 | 64bit | ss.fishmv | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
918 | 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
919
920 Both of these Simple-V operations are illegally-allocated. The fact that
921 there does not exist a scalar "Defined Word" (even for EXT200-263) - the
922 unallocated block - means that the instruction may **not** be allocated in
923 the Simple-V space.
924
925 \newpage{}
926 # Use cases
927
928 In the following examples the programs are fully executable under the
929 Libre-SOC Simple-V-augmented Power ISA Simulator. Reproducible
930 (scripted) Installation instructions:
931 <https://libre-soc.org/HDL_workflow/devscripts/>
932
933 ## LD/ST-Multi
934
935 Context-switching saving and restoring of registers on the stack often
936 requires explicit loop-unrolling to achieve effectively. In SVP64 it
937 is possible to use a Predicate Mask to "compact" or "expand" a swathe
938 of desired registers, dynamically. Known as "VCOMPRESS" and "VEXPAND",
939 runtime-configurable LD/ST-Multi is achievable with 2 instructions.
940
941 ```
942 # load 64 registers off the stack, in-order, skipping unneeded ones
943 # by using CR0-CR63's "EQ" bits to select only those needed.
944 setvli 64
945 sv.ld/sm=EQ *rt,0(ra)
946 ```
947
948 ## Twin-Predication, re-entrant
949
950 This example demonstrates two key concepts: firstly Twin-Predication
951 (separate source predicate mask from destination predicate mask) and
952 that sufficient state is stored within the Vector Context SPR, SVSTATE,
953 for full re-entrancy on a Context Switch or function call *even if
954 in the middle of executing a loop*. Also demonstrates that it is
955 permissible for a programmer to write **directly** to the SVSTATE
956 SPR, and still expect Deterministic Behaviour. It's not exactly recommended
957 (performance may be impacted by direct SVSTATE access), but it is not
958 prohibited either.
959
960 ```
961 292 # checks that we are able to resume in the middle of a VL loop,
962 293 # after an interrupt, or after the user has updated src/dst step
963 294 # let's assume the user has prepared src/dst step before running this
964 295 # vector instruction
965 296 # test_intpred_reentrant
966 297 # reg num 0 1 2 3 4 5 6 7 8 9 10 11 12
967 298 # srcstep=1 v
968 299 # src r3=0b0101 Y N Y N
969 300 # : |
970 301 # + - - + |
971 302 # : +-------+
972 303 # : |
973 304 # dest ~r3=0b1010 N Y N Y
974 305 # dststep=2 ^
975 306
976 307 sv.extsb/sm=r3/dm=~r3 *5, *9
977 ```
978
979 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_predication.py;hb=HEAD>
980
981 ## 3D GPU style "Branch Conditional"
982
983 (*Note: Specification is ready, Simulator still under development of
984 full specification capabilities*)
985 This example demonstrates a 2-long Vector Branch-Conditional only
986 succeeding if *all* elements in the Vector are successful. This
987 avoids the need for additional instructions that would need to
988 perform a Parallel Reduction of a Vector of Condition Register
989 tests down to a single value, on which a Scalar Branch-Conditional
990 could then be performed. Full Rationale at
991 <https://libre-soc.org/openpower/sv/branches/>
992
993 ```
994 80 # test_sv_branch_cond_all
995 81 for i in [7, 8, 9]:
996 83 addi 1, 0, i+1 # set r1 to i
997 84 addi 2, 0, i # set r2 to i
998 85 cmpi cr0, 1, 1, 8 # compare r1 with 10 and store to cr0
999 86 cmpi cr1, 1, 2, 8 # compare r2 with 10 and store to cr1
1000 87 sv.bc/all 12, *1, 0xc # bgt 0xc - branch if BOTH
1001 88 # r1 AND r2 greater 8 to the nop below
1002 89 addi 3, 0, 0x1234, # if tests fail this shouldn't execute
1003 90 or 0, 0, 0 # branch target
1004 ```
1005
1006 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bc.py;hb=HEAD>
1007
1008 \newpage{}
1009 ## DCT
1010
1011 DCT has dozens of uses in Audio-Visual processing and CODECs.
1012 A full 8-wide in-place triple-loop Inverse DCT may be achieved
1013 in 8 instructions. Expanding this to 16-wide is a matter of setting
1014 `svshape 16` **and the same instructions used**.
1015 Lee Composition may be deployed to construct non-power-two DCTs.
1016 The cosine table may be computed (once) with 18 Vector instructions
1017 (one of them `fcos`)
1018
1019 ```
1020 1014 # test_sv_remap_fpmadds_ldbrev_idct_8_mode_4
1021 1015 # LOAD bit-reversed with half-swap
1022 1016 svshape 8, 1, 1, 14, 0
1023 1017 svremap 1, 0, 0, 0, 0, 0, 0
1024 1018 sv.lfs/els *0, 4(1)
1025 1019 # Outer butterfly, iterative sum
1026 1020 svremap 31, 0, 1, 2, 1, 0, 1
1027 1021 svshape 8, 1, 1, 11, 0
1028 1022 sv.fadds *0, *0, *0
1029 1023 # Inner butterfly, twin +/- MUL-ADD-SUB
1030 1024 svshape 8, 1, 1, 10, 0
1031 1025 sv.ffmadds *0, *0, *0, *8
1032 ```
1033
1034 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;hb=HEAD>
1035
1036 ## Matrix Multiply
1037
1038 Matrix Multiply of any size (non-power-2) up to a total of 127 operations
1039 is achievable with only three instructions. Normally in any other SIMD
1040 ISA at least one source requires Transposition and often massive rolling
1041 repetition of data is required. These 3 instructions may be used as the
1042 "inner triple-loop kernel" of the usual 6-loop Massive Matrix Multiply.
1043
1044 ```
1045 28 # test_sv_remap1 5x4 by 4x3 matrix multiply
1046 29 svshape 5, 4, 3, 0, 0
1047 30 svremap 31, 1, 2, 3, 0, 0, 0
1048 31 sv.fmadds *0, *8, *16, *0
1049 ```
1050
1051 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;hb=HEAD>
1052
1053 ## Parallel Reduction
1054
1055 Parallel (Horizontal) Reduction is often deeply problematic in SIMD and
1056 Vector ISAs. Parallel Reduction is Fully Deterministic in Simple-V and
1057 thus may even usefully be deployed on non-associative and non-commutative
1058 operations.
1059
1060 ```
1061 75 # test_sv_remap2
1062 76 svshape 7, 0, 0, 7, 0
1063 77 svremap 31, 1, 0, 0, 0, 0, 0 # different order
1064 78 sv.subf *0, *8, *16
1065 79
1066 80 REMAP sv.subf RT,RA,RB - inverted application of RA/RB
1067 81 left/right due to subf
1068 ```
1069
1070 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_parallel_reduce.py;hb=HEAD>
1071
1072 [[!tag opf_rfc]]
1073
1074 [^msr]: an MSR bit or bits, conceptually equivalent to `MSR.SF` and added for the same reasons, would suffice perfectly.
1075 [^extend]: Prefix opcode space (or MSR bits) **must** be reserved in advance to do so, in order to avoid the catastrophic binary-incompatibility mistake made by RISC-V RVV and ARM SVE/2
1076 [^likeext001]: SVP64-Single is remarkably similar to the "bit 1" of EXT001 being set to indicate that the 64-bits is to be allocated in full to a new encoding, but in fact SVP64-single still embeds v3.0 Scalar operations.
1077 [^pseudorewrite]: elwidth overrides does however mean that all SFS / SFFS pseudocode will need rewriting to be in terms of XLEN. This has the indirect side-effect of automatically making a 32-bit Scalar Power ISA Specification possible, as well as a future 128-bit one (Cross-reference: RISC-V RV32 and RV128
1078 [^only2]: reminder that this proposal only needs 75% of two POs for Scalar instructions. The rest of EXT200-263 is for general use.
1079 [^ext001]: Recall that EXT100 to EXT163 is for Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, from Section 1.6.3, bit 6 is set to 1. This concept is where the above scheme originated. Section 1.6.3 uses the term "defined word" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively
1080 [^futurevsx]: A future version or other Stakeholder *may* wish to drop Simple-V onto VSX: this would be a separate RFC
1081 [^vsx256]: imagine a hypothetical future VSX-256 using the exact same instructions as VSX. the binary incompatibility introducrd would catastrophically **and retroactively** damage existing IBM POWER8,9,10 hardware's reputation and that of Power ISA overall.
1082 [^autovec]: Compiler auto-vectorisation for best exploitation of SIMD and Vector ISAs on Scalar programming languages (c, c++) is an Indusstry-wide known-hard decades-long problem. Cross-reference the number of hand-optimised assembler algorithms.
1083 [^hphint]: intended for use when the compiler has determined the extent of Memory or register aliases in loops: `a[i] += a[i+4]` would necessitate a Vertical-First hphint of 4