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