1 # OPF ISA WG External RFC LS001 v3 24mar2023
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, and NGI0 Entrust No 101069594
9 * <https://git.openpower.foundation/isa/PowerISA/issues/64>
11 * <https://bugs.libre-soc.org/show_bug.cgi?id=924>
13 This proposal is to extend the Power ISA with an Abstract RISC-Paradigm
14 Vectorization Concept that may be orthogonally applied to **all and any**
15 suitable Scalar instructions, present and future, in the Scalar Power ISA.
16 The Vectorization System is called
17 ["Simple-V"](https://libre-soc.org/openpower/sv/)
18 and the Prefix Format is called
19 ["SVP64"](https://libre-soc.org/openpower/sv/).
20 **Simple-V is not a Traditional Vector ISA and therefore
21 does not add Vector opcodes or regfiles**.
22 An ISA Concept similar to Simple-V was originally invented in 1994 by
23 Peter Hsu (Architect of the MIPS R8000) but was dropped as MIPS did not
24 have an Out-of-Order Microarchitecture at the time.
26 Simple-V is designed for Embedded Scenarios right the way through
27 Audio/Visual DSPs to 3D GPUs and Supercomputing. As it does **not**
28 add actual Vector Instructions, relying solely and exclusively on the
29 **Scalar** ISA, it is **Scalar** instructions that need to be added to
30 the **Scalar** Power ISA before Simple-V may orthogonally Vectorize them.
32 The goal of RED Semiconductor Ltd, an OpenPOWER
33 Stakeholder, is to bring to market mass-volume general-purpose compute
34 processors that are competitive in the 3D GPU Audio Visual DSP EDGE IoT
35 desktop chromebook netbook smartphone laptop markets, performance-leveraged
36 by Simple-V. To achieve this goal both Simple-V and accompanying
37 **Scalar** Power ISA instructions are needed. 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)
43 operations present in ARM
44 Intel AMD and many other ISAs.
45 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 as the primary motivation is to create a **Hybrid 3D CPU-GPU-VPU ISA**
55 it becomes necesary to consider the Architectural Resource
56 Allocation of not just Simple-V but the 80-100 Scalar instructions all
59 It is also critical to note that Simple-V **does not modify the Scalar
60 Power ISA**, that **only** Scalar words may be
61 Vectorized, and that Vectorized instructions are **not** permitted to be
62 different from their Scalar words (`addi` must use the same Word encoding
63 as `sv.addi`, and any new Prefixed instruction added **must** also
65 The sole semi-exception is Vectorized
66 Branch Conditional, in order to provide the usual Advanced Branching
67 capability present in every Commercial 3D GPU ISA, but it
68 is the *Vectorized* Branch-Conditional that is augmented, not Scalar
73 The inspiration for Simple-V came from the fact that on examination of every
74 Vector ISA pseudocode encountered the Vector operations were expressed
75 as a for-loop on a Scalar element
76 operation, and then both a Scalar **and** a Vector instruction was added.
78 [Zero-Overhead Looping](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
79 *already* being common for over four
80 decades it felt natural to separate the looping at both the ISA and
82 and thus provide only Scalar instructions (instantly halving the number
83 of instructions), but rather than go the VLIW route (TI MSP Series)
84 keep closely to existing Power ISA standard Scalar execution.
86 Thus the basic principle of Simple-V is to provide a Precise-Interruptible
87 Zero-Overhead Loop system[^zolc] with associated register "offsetting"
88 which augments a Suffixed instruction as a "template",
89 incrementing the register numbering progressively *and automatically*
90 each time round the "loop". Thus it may be considered to be a form
91 of "Sub-Program-Counter" and at its simplest level can replace a large
92 sequence of regularly-increasing loop-unrolled instructions with just two:
93 one to set the Vector length and one saying where to
94 start from in the regfile.
96 On this sound and profoundly simple concept which leverages *Scalar*
97 Micro-architectural capabilities much more comprehensive festures are
98 easy to add, working up towards an ISA that easily matches the capability
99 of powerful 3D GPU Vector Supercomputing ISAs, without ever adding even
100 one single Vector opcode.
104 Simple-V has been subdivided into levels akin to the Power ISA Compliancy
105 Levels. For now let us call them "SV Extension Levels" to differentiate
106 the two. The reason for the
107 [SV Extension Levels](https://libre-soc.org/openpower/sv/compliancy_levels/)
108 is the same as for the
109 Power ISA Compliancy Levels (SFFS, SFS): to not overburden implementors
110 with features that they do not need. *There is no dependence between
111 the two types of Levels*. The resources below therefore are
112 not all required for all SV Extension Levels but they are all required
115 # Binary Interoperability
117 Power ISA has a reputation as being long-term stable.
118 **Simple-V guarantees binary interoperability** by defining fixed
119 register file bitwidths and size for a given set of instructions.
120 The seduction of permitting different implementors to choose a register file
121 bitwidth and size with the same instructions unfortunately has
122 the catastrophic side-effect of introducing not only binary incompatibility
123 but silent data corruption as well as no means to trap-and-emulate differing
126 "Silicon-Partner" Scalability is identical to attempting to run 64-bit
127 Power ISA binaries without setting - or having `MSR.SF` - on "Scaled"
128 32-bit hardware: **the same opcodes** were shared between 32 and 64 bit.
129 `RESERVED` space is thus crucial
130 to have, in order to provide the **OPF ISA WG** - not implementors
131 ("Silicon Partners") - with the option to properly review and decide
132 any (if any) future expanded register file bitwidths and sizes[^msr],
133 **under explicitly-distinguishable encodings** so as to guarantee
134 long-term stability and binary interoperability.
136 # Hardware Implementations
138 The fundamental principle of Simple-V is that it sits between Issue and
139 Decode, pausing the Program-Counter to service a "Sub-PC"
140 hardware for-loop. This is very similar to
141 [Zero-Overhead Loops](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
142 in High-end DSPs (TI MSP Series).
144 Considerable effort has been expended to ensure that Simple-V is
145 practical to implement on an extremely wide range of Industry-wide
146 common **Scalar** micro-architectures. Finite State Machine (for
147 ultra-low-resource and Mission-Critical), In-order single-issue, all the
148 way through to Great-Big Out-of-Order Superscalar Multi-Issue. The
149 SV Extension Levels specifically recognise these differing scenarios.
151 SIMD back-end ALUs particularly those with element-level predicate
152 masks may be exploited to good effect with very little additional
153 complexity to achieve high throughput, even on a single-issue in-order
154 microarchitecture. As usually becomes quickly apparent with in-order, its
155 limitations extend also to when Simple-V is deployed, which is why
156 Multi-Issue Out-of-Order is the recommended (but not mandatory) Scalar
157 Micro-architecture. Byte-level write-enable regfiles (like SRAMs) are
158 strongly recommended, to avoid a Read-Modify-Write cycle.
160 The only major concern is in the upper SV Extension Levels: the Hazard
161 Management for increased number of Scalar Registers to 128 (in current
162 versions) but given that IBM POWER9/10 has VSX register numbering 64,
163 and modern GPUs have 128, 256 and even 512 registers this was deemed
164 acceptable. Strategies do exist in hardware for Hazard Management of
165 such large numbers of registers, even for Multi-Issue microarchitectures.
167 # Simple-V Architectural Resources
169 * No new Interrupt types are required.
170 No modifications to existing Power ISA opcodes are required.
171 No new Register Files are required (all because Simple-V is a category of
172 Zero-Overhead Looping on Scalar instructions)
173 * GPR FPR and CR Field Register extend to 128. A future
174 version may extend to 256 or beyond[^extend] or also extend VSX[^futurevsx]
175 * 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO)
176 * Another 24-bit (a second 2-bit XO) is needed for a planned future encoding,
177 currently named "SVP64-Single"[^likeext001]
178 * A third 24-bits (third 2-bit XO) is strongly recommended to be `RESERVED`
179 such that future unforeseen capability is needed (although this may be
180 alternatively achieved with a mandatory PCR or MSR bit)
181 * To hold all Vector Context, four SPRs are needed.
182 (Some 32/32-to-64 aliases are advantageous but not critical).
183 * Five 6-bit XO (A-Form) "Management" instructions are needed. These are
184 Scalar 32-bit instructions and *may* be 64-bit-extended in future as
187 **Summary of Simple-V Opcode space**
189 * 50% of a new 64-bit Encoding (PO9)
190 * Five 6-bit XO 32-bit "Management" operations.
192 No further opcode space *for Simple-V* is envisaged to be required for
193 at least the next decade (including if added on VSX). EXT1xx variants
194 of the Management Operations are anticipated for a future revision.
198 * **SVSTATE** - 64-bit Vectorization State sufficient for Precise-Interrupt
199 Context-switching and no adverse latency, it may be considered to
200 be a "Sub-PC" and as such absolutely must be treated with the same
201 respect and priority as MSR and PC.
202 * **SVSHAPE0-3** - these are 32-bit and may be grouped in pairs, they REMAP
203 (shape) the Vectors[^svshape]
204 * **SVLR** - again similar to LR for exactly the same purpose, SVSTATE
205 is swapped with SVLR by SV-Branch-Conditional for exactly the same
206 reason that NIA is swapped with LR
208 *Resource Allocation Note: Allocation of SVSTATE needs to take into consideration
209 seven additional future SVSTATE SPRs to be used as a "stack" as part of a full
210 Zero-Overhead Loop Control subsystem.*
212 **Vector Management Instructions**
214 These fit into QTY 5of 6-bit XO 32-bit encoding (svshape and svshape2 share
217 * **setvl** - Cray-style Scalar Vector Length instruction
218 * **svstep** - used for Vertical-First Mode and for enquiring about internal
220 * **svremap** - "tags" registers for activating REMAP
221 * **svshape** - convenience instruction for quickly setting up Matrix, DCT,
222 FFT and Parallel Reduction REMAP
223 * **svshape2** - additional convenience instruction to set up "Offset" REMAP
224 (fits within svshape's XO encoding)
225 * **svindex** - convenience instruction for setting up "Indexed" REMAP.
227 *Resource Allocation Note: these must be allocated in EXT0xx as they will be
228 EXT1xx Prefixed in future.*
232 # SVP64 24-bit Prefixes
234 The SVP64 24-bit Prefix (RM) options aim to reduce instruction count
235 and assembler complexity.
236 These Modes do not interact with SVSTATE per se. SVSTATE
237 primarily controls the looping (quantity, order), RM
238 influences the *elements* (the Suffix). There is however
239 some close interaction when it comes to predication.
240 REMAP is outlined separately.
242 * **element-width overrides**, which dynamically redefine each SFFS or SFS
243 Scalar prefixed instruction to be 8-bit, 16-bit, 32-bit or 64-bit
244 operands **without requiring new 8/16/32 instructions.**[^pseudorewrite]
245 This results in full BF16 and FP16 opcodes being added to the Power ISA
246 **without adding BF16 or FP16 opcodes** including full conversion
249 this is an absolutely essential feature for a 3D GPU VPU ISA.
250 CR Fields are available as Predicate Masks hence the reason for their
251 extension to 128. Twin-Predication is also provided: this may best
252 be envisaged as back-to-back VGATHER-VSCATTER but is not restricted
253 to LD/ST, its use saves on instruction count. Enabling one or other
254 of the predicates provides all of the other types of operations
255 found in Vector ISAs (VEXTRACT, VINSERT etc) again with no need
256 to actually provide explicit such instructions.
257 * **Saturation**. applies to **all** LD/ST and Arithmetic and Logical
258 operations (without adding explicit saturation ops)
259 * **Reduction and Prefix-Sum** (Fibonnacci Series) Modes, including a
260 "Reverse Gear" (running loops backwards).
261 * **vec2/3/4 "Packing" and "Unpacking"** (similar to VSX `vpack` and `vpkss`)
262 accessible in a way that is easier than REMAP, added for the same reasons
263 that drove `vpack` and `vpkss` etc. to be added: pixel, audio, and 3D
264 data manipulation. With Pack/Unpack being part of SVSTATE it can be
265 applied *in-place* saving register file space (no copy/mv needed).
266 * **Load/Store "fault-first"** speculative behaviour,
267 identical to SVE and RVV
268 Fault-first: provides auto-truncation of a speculative sequential parallel
270 solve the "SIMD Considered Harmful" stripmining problem from a Memory
272 * **Data-Dependent Fail-First**: a 100% Deterministic extension of the LDST
273 ffirst concept: first `Rc=1 BO test` failure terminates looping and
274 truncates VL to that exact point. Useful for implementing algorithms
275 such as `strcpy` in around 14 high-performance Vector instructions, the
276 option exists to include or exclude the failing element.
280 There are five primary categories of instructions in Power ISA, each of
281 which needed slightly different Modes. For example, saturation and
282 element-width overrides are meaningless to Condition Register Field
283 operations, and Reduction is meaningless to LD/ST but Saturation
284 saves register file ports in critical hot-loops. Thus the 24 bits may
285 be suitably adapted to each category.
287 * Normal - arithmetic and logical including IEEE754 FP
288 * LD/ST immediate - includes element-strided and unit-strided
291 * Branch-Conditional - saves on instruction count in 3D parallel if/else
293 It does have to be pointed out that there is huge pressure on the
294 Mode bits. There was therefore insufficient room, unlike the way that
295 EXT001 was designed, to provide "identifying bits" *without first partially
296 decoding the Suffix*.
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.
308 **Vectorized Branch-Conditional**
310 As mentioned in the introduction this is the one sole instruction group
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.
316 The two additional Modes within Vectorized 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.
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 up to **twelve** instructions
329 especially given the close interaction with CTR in hot-loops.[^parity]
331 [^parity]: adding a parity (XOR) option was too much. instead a parallel-reduction on `crxor` may be used in combination with a Scalar Branch.
333 Also `SVLR` is introduced, which is a parallel twin of `LR`, and saving
334 and restoring of LR and SVLR may be deferred until the final decision
335 as to whether to branch. In this way `sv.bclrl` does not corrupt `LR`.
337 Vectorized Branch-Conditional due to its side-effects (e.g. reducing CTR
338 or truncating VL) has practical uses even if the Branch is deliberately
339 set to the next instruction (CIA+8). For example it may be used to reduce
340 CTR by the number of bits set in a GPR, if that GPR is given as the predicate
345 Traditional Vector ISAs have vastly more (and more complex) addressing
346 modes than Scalar ISAs: unit strided, element strided, Indexed, Structure
347 Packing. All of these had to be jammed in on top of existing Scalar
348 instructions **without modifying or adding new Scalar instructions**.
349 A small conceptual "cheat" was therefore needed. The Immediate (D)
350 is in some Modes multiplied by the element index, which gives us
351 element-strided. For unit-strided the width of the operation (`ld`,
352 8 byte) is multiplied by the element index and *substituted* for "D"
353 when the immediate, D, is zero. Modifications to support this "cheat"
354 on top of pre-existing Scalar HDL (and Simulators) have both turned
355 out to be minimal.[^mul] Also added was the option to perform signed
356 or unsigned Effective Address calculation, which comes into play only
357 on LD/ST Indexed, when elwidth overrides are used. Another quirk:
358 `RA` is never allowed to have its width altered: it remains 64-bit,
359 as it is the Base Address.
361 One confusing thing is the unfortunate naming of LD/ST Indexed and
362 REMAP Indexed: some care is taken in the spec to discern the two.
363 LD/ST Indexed is Scalar `EA=RA+RB` (where **either** RA or RB
364 may be marked as Vectorized), where obviously the order in which
365 that Vector of RA (or RB) is read in the usual linear sequential
366 fashion. REMAP Indexed affects the
367 **order** in which the Vector of RA (or RB) is accessed,
368 according to a schedule determined by *another* vector of offsets
369 in the register file. Effectively this combines VSX `vperm`
370 back-to-back with LD/ST operations *in the calculation of each
371 Effective Address* in one instruction.
373 For DCT and FFT, normally it is very expensive to perform the
374 "bit-inversion" needed for address calculation and/or reordering
375 of elements. DCT in particular needs both bit-inversion *and
376 Gray-Coding* offsets (a complexity that often "justifies" full
377 assembler loop-unrolling). DCT/FFT REMAP **automatically** performs
378 the required offset adjustment to get data loaded and stored in
379 the required order. Matrix REMAP can likewise perform up to 3
380 Dimensions of reordering (on both Immediate and Indexed), and
381 when combined with vec2/3/4 the reordering can even go as far as
382 four dimensions (four nested fixed size loops).
384 Twin Predication is worth a special mention. Many Vector ISAs have
385 special LD/ST `VCOMPRESS` and `VREDUCE` instructions, which sequentially
386 skip elements based on predicate mask bits. They also add special
387 `VINSERT` and `VEXTRACT` Register-based instructions to compensate
388 for lack of single-element LD/ST (where in Simple-V you just use
389 Scalar LD/ST). Also Broadcasting (`VSPLAT`) is either added to LDST
390 or as Register-based.
392 *All of the above modes are covered by Twin-Predication*
394 In particular, a special predicate mode `1<<r3` uses the register `r3`
395 *binary* value, converted to single-bit unary mask,
396 effectively as a single (Scalar) Index *runtime*-dynamic offset into
397 a Vector.[^r3] Combined with the
398 (mis-named) "mapreduce" mode when used as a source predicate
399 a `VSPLAT` (broadcast) is performed. When used as a destination
401 provides `VINSERT` behaviour.
403 [^r3]: Effectively: `GPR(RA+r3)`
405 Also worth an explicit mention is that Twin Predication when using
406 different source from destination predicate masks effectively combines
407 back-to-back `VCOMPRESS` and `VEXPAND` (in a single instruction), and,
408 further, that the benefits of Twin Predication are not limited to LD/ST,
409 they may be applied to Arithmetic, Logical and CR Field operations as well.
411 Overall the LD/ST Modes available are astoundingly powerful, especially
412 when combining arithmetic (lharx) with saturation, element-width overrides,
414 vec2/3/4 Structure Packing *and* REMAP, the combinations far exceed anything
415 seen in any other Vector ISA in history, yet are really nothing more
416 than concepts abstracted out in pure RISC form.[^ldstcisc]
420 CR Field operations (`crand` etc.) are somewhat underappreciated in the
421 Power ISA. The CR Fields however are perfect for providing up to four
422 separate Vectors of Predicate Masks: `EQ LT GT SO` and thus some special
423 attention was given to first making transfer between GPR and CR Fields
424 much more powerful with the
425 [crweird](https://libre-soc.org/openpower/sv/cr_int_predication/)
426 operations, and secondly by adding powerful binary and ternary CR Field
427 operations into the bitmanip extension.[^crops]
429 On these instructions RM Modes may still be applied (mapreduce and Data-Dependent Fail-first). The usefulness of
430 being able to auto-truncate subsequent Vector Processing at the point
431 at which a CR Field test fails, based on any arbitary logical operation involving `three` CR Field Vectors (`crternlogi`) should be clear, as
432 should the benefits of being able to do mapreduce and REMAP Parallel
433 Reduction on `crternlogi`: dramatic reduction in instruction count
434 for Branch-based control flow when faced with complex analysis of
435 multiple Vectors, including XOR-reduction (parity).
437 Overall the addition of the CR Operations and the CR RM Modes is about
438 getting instruction count down and increasing the power and flexibility of CR Fields as pressed into service for the purpose of Predicate Masks.
440 [^crops]: the alternative to powerful transfer instructions between GPR and CR Fields was to add the full duplicated suite of BMI and TBM operations present in GPR (popcnt, cntlz, set-before-first) as CR Field Operations. all of which was deemed inappropriate.
442 # SVP64Single 24-bits
444 The `SVP64-Single` 24-bit encoding focusses primarily on ensuring that
445 all 128 Scalar registers are fully accessible, provides element-width
446 overrides, one-bit predication
447 and brings Saturation to all existing Scalar operations.
448 BF16 and FP16 are thus
449 provided in the Scalar Power ISA without one single explicit FP16 or BF16
450 32-bit opcode being added. The downside: such Scalar operations are
451 all 64-bit encodings.
453 As SVP64Single is new and still under development, space for it may
454 instead be `RESERVED`. It is however necessary in *some* form
455 as there are limitations
456 in SVP64 Register numbering, particularly for 4-operand instructions,
457 that can only be easily overcome by SVP64Single.
459 # Vertical-First Mode
461 This is a Computer Science term that needed first to be invented.
462 There exists only one other Vertical-First Vector ISA in the world:
463 Mitch Alsup's VVM Extension for the 66000, details of which may be
464 obtained publicly on `comp.arch` or directly from Mitch Alsup under
465 NDA. Several people have
466 independently derived Vertical-First: it simply did not have a
467 Computer Science term associated with it.
469 If we envisage register and Memory layout to be Horizontal and
470 instructions to be Vertical, and to then have some form of Loop
471 System (wherther Zero-Overhead or just branch-conditional based)
472 it is easier to then conceptualise VF vs HF Mode:
474 * Vertical-First progresses through *instructions* first before
475 moving on to the next *register* (or Memory-address in the case
476 of Mitch Alsup's VVM).
477 * Horizontal-First (also known as Cray-style Vectors) progresses
478 through **registers** (or, register *elements* in traditional
479 Cray-Vector ISAs) in full before moving on to the next *instruction*.
481 Mitch Alsup's VVM Extension is a form of hardware-level auto-vectorization
482 based around Zero-Overhead Loops. Using a Variable-Length Encoding all
483 loop-invariant registers are "tagged" such that the Hazard Management
484 Engine may perform optimally and do less work in automatically identifying
485 parallelism opportunities.
486 With it not being appropriate to use Variable-Length Encoding in the Power
487 ISA a different much more explicit strategy was taken in Simple-V.
489 The biggest advantage inherent in Vertical-First is that it is very easy
490 to introduce into compilers, because all looping, as far as programs
491 is concerned, remains expressed as *Scalar assembler*.[^autovec]
493 VVM biggest strength is its hardware-level auto-vectorization
494 but is limited in its ability to call
495 functions, Simple-V's Vertical-First provides explicit control over the
496 parallelism ("hphint")[^hphint] and also allows for full state to be stored/restored
497 (SVLR combined with LR), permitting full function calls to be made
498 from inside Vertical-First Loops, and potentially allows arbitrarily-depth
501 Simple-V Vertical-First Looping requires an explicit instruction to
502 move `SVSTATE` regfile offsets forward: `svstep`. An early version of
504 Branch-Conditional attempted to merge the functionality of `svstep`
505 into `sv.bc`: it became CISC-like in its complexity and was quickly reverted.
507 # Simple-V REMAP subsystem
509 [REMAP](https://libre-soc.org/openpower/sv/remap)
510 is extremely advanced but brings features already present in other
511 DSPs and Supercomputing ISAs. The usual sequential progression
512 through elements is pushed through a hardware-defined
513 *fully Deterministic*
514 "remapping". Normally (without REMAP)
515 algorithms are costly or
516 convoluted to implement. They are typically implemented
517 as hard-coded fully loop-unrolled assembler which is often
518 auto-generated by specialist tools, or written
520 All REMAP Schedules *including Indexed*
521 are 100% Deterministic from their point of declaration,
522 making it possible to forward-plan
523 Issue, Memory access and Register Hazard Management
524 in Multi-Issue Micro-architectures.
526 If combined with Vertical-First then much more complex operations may exploit
527 REMAP Schedules, such as Complex Number FFTs, by using Scalar intermediary
528 temporary registers to compute results that have a Vector source
529 or destination or both.
530 Contrast this with a Standard Horizontal-First Vector ISA where the only
531 way to perform Vectorized Complex Arithmetic would be to add Complex Vector
532 Arithmetic operations, because due to the Horizontal (element-level)
533 progression there is no way to utilise intermediary temporary (scalar)
536 [^complex]: a case could be made for constructing Complex number arithmetic using multiple sequential Horizontal-First (Cray-style Vector) instructions. This may not be convenient in the least when REMAP is involved (such as Parallel Reduction of Complex Multiply).
538 * **DCT/FFT** REMAP brings more capability than TI's MSP-Series DSPs and
539 Qualcom Hexagon DSPs, and is not restricted to Integer or FP.
540 (Galois Field is possible, implementing NTT). Operates *in-place*
541 significantly reducing register usage.
542 * **Matrix** REMAP brings more capability than any other Matrix Extension
543 (AMD GPUs, Intel, ARM), not being restricted to Power-2 sizes. Also not
544 limited to the type of operation, it may perform Warshall Transitive
545 Closure, Integer Matrix, Bitmanipulation Matrix, Galois Field (carryless
546 mul) Matrix, and with care potentially Graph Maximum Flow as well. Also
547 suited to Convolutions, Matrix Transpose and rotate, *all* of which is
549 * **General-purpose Indexed** REMAP, this option is provided to implement
550 an equivalent of VSX `vperm`, as a general-purpose catch-all means of
551 covering algorithms outside of the other REMAP Engines.
552 * **Parallel Reduction** REMAP, performs an automatic map-reduce using
553 *any suitable scalar operation*.
555 All REMAP Schedules are Precise-Interruptible. No latency penalty is caused by
556 the fact that the Schedule is Parallel-Reduction, for example. The operations
557 are Issued (Deterministically) as **Scalar** operations and thus any latency
558 associated with **Scalar** operation Issue exactly as in a **Scalar**
559 Micro-architecture will result. Contrast this with a Standard Vector ISA
560 where frequently there is either considerable interrupt latency due to
561 requiring a Parallel Reduction to complete in full, or partial results
562 to be discarded and re-started should a high-priority Interrupt occur
565 Note that predication is possible on REMAP but is hard to use effectively.
566 It is often best to make copies of data (`VCOMPRESS`) then apply REMAP.
571 The primary reason for mentioning the additional Scalar operations
572 is because they are so numerous, with Power ISA not having advanced
573 in the *general purpose* compute area in the past 12 years, that some
574 considerable care is needed.
577 **Including Simple-V, to fit everything at least 75% of 3 separate
578 Major Opcodes would be required**
580 Candidates (for all but the X-Form instructions) include:
583 * EXT017 (75% free but not recommended)
587 * brownfield space in EXT019 (25% but NOT recommended)
589 SVP64, SVP64-Single and SVP64-Reserved would require on their own each 25%
590 of one Major Opcode for a total of 75% of one Major Opcode. The remaining
591 **Scalar** opcodes, due to there being two separate sets of operations
592 with 16-bit immediates, will require the other space totalling two 75%
595 Note critically that:
597 * Unlike EXT001, SVP64's 24-bits may **not** hold also any Scalar
598 operations. There is no free available space: a 25th bit would
599 be required. The entire 24-bits is **required** for the abstracted
600 Hardware-Looping Concept **even when these 24-bits are zero**
601 * Any Scalar 64-bit instruction (regardless of how it is encoded) is unsafe to
602 then Vectorize because this creates the situation of Prefixed-Prefixed,
603 resulting in deep complexity in Hardware Decode at a critical juncture, as
604 well as introducing 96-bit instructions.
605 * **All** of these Scalar instructions are candidates for Vectorization.
606 Thus none of them may be 64-bit-Scalar-only.
608 **Minor Opcodes to fit candidates above**
610 In order of size, for bitmanip and A/V DSP purposes:
612 * QTY 3of 2-bit XO: ternlogi, crternlogi, grevlogi
613 * QTY 7of 3-bit XO: xpermi, binlut, grevlog, swizzle-mv/fmv, bitmask, bmrevi
614 * QTY 8of 5/6-bit (A-Form): xpermi, bincrflut, bmask, fmvis, fishmv, bmrev,
616 * QTY 30of 10-bit (X-Form): cldiv/mul, av-min/max/diff, absdac, xperm etc.
617 (easily fit EXT019, EXT031).
619 Note: Some of the Galois Field operations will require QTY 1of Polynomial
620 SPR (per userspace supervisor hypervisor).
624 For biginteger math, two instructions in the same space as "madd" are to
625 be proposed. They are both 3-in 2-out operations taking or producing a
626 64-bit "pair" (like RTp), and perform 128/64 mul and div/mod operations
627 respectively. These are **not** the same as VSX operations which are
628 128/128, and they are **not** the same as existing Scalar mul/div/mod,
629 all of which are 64/64 (or 64/32).
631 **EXT059 and EXT063**
633 Additionally for High-Performance Compute and Competitive 3D GPU, IEEE754 FP
634 Transcendentals are required, as are some DCT/FFT "Twin-Butterfly" operations.
635 For each of EXT059 and EXT063:
637 * QTY 33of X-Form "1-argument" (fsin, fsins, fcos, fcoss)
638 * QTY 15of X-Form "2-argument" (pow, atan2, fhypot)
639 * QTY 5of A-Form "3-in 2-out" FP Butterfly operations for DCT/FFT
640 * QTY 8of X-Form "2-in 2-out" FP Butterfly operations (again for DCT/FFT)
641 * An additional 16 instructions for IEEE754-2019
642 (fminss/fmaxss, fminmag/fmaxmag)
643 [under evaluation](https://bugs.libre-soc.org/show_bug.cgi?id=923)
646 # Adding new opcodes.
648 With Simple-V being a type of
649 [Zero-Overhead Loop](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
651 Scalar operations some clear guidelines are needed on how both
652 existing "Defined Word-instructions" (Public v3.1 Section 1.6.3 term) and future
653 Scalar operations are added within the 64-bit space. Examples of
654 legal and illegal allocations are given later.
656 The primary point is that once an instruction is defined in Scalar
657 32-bit form its corresponding space **must** be reserved in the
658 SVP64 area with the exact same 32-bit form, even if that instruction
659 is "Unvectorizeable" (`sc`, `sync`, `rfid` and `mtspr` for example).
660 Instructions may **not** be added in the Vector space without also
661 being added in the Scalar space, and vice-versa, *even if Unvectorizeable*.
663 This is extremely important because the worst possible situation
664 is if a conflicting Scalar instruction is added by another Stakeholder,
665 which then turns out to be Vectorizeable: it would then have to be
666 added to the Vector Space with a *completely different Defined Word-instruction*
667 and things go rapidly downhill in the Decode Phase from there.
668 Setting a simple inviolate rule helps avoid this scenario but does
669 need to be borne in mind when discussing potential allocation
670 schemes, as well as when new Vectorizeable Opcodes are proposed
671 for addition by future RFCs: the opcodes **must** be uniformly
672 added to Scalar **and** Vector spaces, or added in one and reserved
674 not added at all in either.[^whoops]
677 # Potential Opcode allocation solution (superseded)
679 *Note this scheme is superseded below but kept for completeness as it
680 defines terms and context*.
681 There are unfortunately some inviolate requirements that directly place
682 pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that
683 it risks jeapordising the Power ISA. These requirements are:
685 * all of the scalar operations must be Vectorizeable
686 * all of the scalar operations intended for Vectorization
687 must be in a 32-bit encoding (not prefixed-prefixed to 96-bit)
688 * bringing Scalar Power ISA up-to-date from the past 12 years
689 needs 75% of two Major opcodes all on its own
691 There exists a potential scheme which meets (exceeds) the above criteria,
692 providing plenty of room for both Scalar (and Vectorized) operations,
693 *and* provides SVP64-Single with room to grow. It
694 is based loosely around Public v3.1 EXT001 Encoding.[^ext001]
696 | 0-5 | 6 | 7 | 8-31 | Description |
697 |-----|---|---|-------|---------------------------|
698 | PO | 0 | 0 | 0000 | new-suffix `RESERVED1` |
699 | PO | 0 | 0 | !zero | new-suffix, scalar (SVP64Single), or `RESERVED3` |
700 | PO | 1 | 0 | 0000 | new scalar-only word, or `RESERVED2` |
701 | PO | 1 | 0 | !zero | old-suffix, scalar (SVP64Single), or `RESERVED4` |
702 | PO | 0 | 1 | nnnn | new-suffix, vector (SVP64) |
703 | PO | 1 | 1 | nnnn | old-suffix, vector (SVP64) |
705 * **PO** - Primary Opcode. Likely candidates: EXT005, EXT009
706 * **bit 6** - specifies whether the suffix is old (EXT000-EXT063)
707 or new (EXTn00-EXTn63, n greater than 1)
708 * **bit 7** - defines whether the Suffix is Scalar-Prefixed or Vector-Prefixed
709 (caveat: see bits 8-31)
710 * **old-suffix** - the EXT000 to EXT063 32-bit Major opcodes of Power ISA 3.0
711 * **new scalar-only** - a **new** Major Opcode area **exclusively**
712 for Scalar-only instructions that shall **never** be Prefixed by SVP64
713 (RESERVED2 EXT300-EXT363)
714 * **new-suffix** - a **new** Major Opcode area (RESERVED1 EXT200-EXT263)
715 that **may** be Prefixed by SVP64 and SVP64Single
716 * **0000** - all 24 bits bits 8-31 are zero (0x000000)
717 * **!zero** - bits 8-31 may be any value *other* than zero (0x000001-0xffffff)
718 * **nnnn** - bits 8-31 may be any value in the range 0x000000 to 0xffffff
719 * **SVP64Single** - a ([TBD](https://bugs.libre-soc.org/show_bug.cgi?id=905))
720 *Scalar* Encoding that is near-identical to SVP64
721 except that it is equivalent to hard-coded VL=1
722 at all times. Predication is permitted, Element-width-overrides is
723 permitted, Saturation is permitted.
724 If not allocated within the scope of this RFC
725 then these are requested to be `RESERVED` for a future Simple-V
727 * **SVP64** - a (well-defined, 2 years) DRAFT Proposal for a Vectorization
728 Augmentation of suffixes.
730 For the needs identified by Libre-SOC (75% of 2 POs),
731 `RESERVED1` space *needs*
732 allocation to new POs, `RESERVED2` does not.[^only2]
734 | | Scalar (bit7=0,8-31=0000) | Scalar (bit7=0,8-31=!zero)| Vector (bit7=1) |
735 |----------|---------------------------|---------------------------|------------------|
736 |new bit6=0| `RESERVED1`:{EXT200-263} | `RESERVED3`:SVP64-Single:{EXT200-263} | SVP64:{EXT200-263} |
737 |old bit6=1| `RESERVED2`:{EXT300-363} | `RESERVED4`:SVP64-Single:{EXT000-063} | SVP64:{EXT000-063} |
739 * **`RESERVED2`:{EXT300-363}** (not strictly necessary to be added) is not
740 and **cannot** ever be Vectorized or Augmented by Simple-V or any future
742 it is a pure **Scalar-only** word-length PO Group. It may remain `RESERVED`.
743 * **`RESERVED1`:{EXT200-263}** is also a new set of 64 word-length Major
745 These opcodes would be Simple-V-Augmentable
746 unlike `EXT300-363` which may **never** be Simple-V-Augmented
747 under any circumstances.
748 * **RESERVED3:`SVP64-Single:{EXT200-263}`** - Major opcodes 200-263 with
749 Single-Augmentation, providing a one-bit predicate mask, element-width
750 overrides on source and destination, and the option to extend the Scalar
751 Register numbering (r0-32 extends to r0-127). **Placing of alternative
752 instruction encodings other than those exactly defined in EXT200-263
754 * **RESERVED4:`SVP64-Single:{EXT000-063}`** - Major opcodes 000-063 with
755 Single-Augmentation, just like SVP64-Single on EXT200-263, these are
756 in effect Single-Augmented-Prefixed variants of the v3.0 32-bit Power ISA.
757 Alternative instruction encodings other than the exact same 32-bit word
758 from EXT000-EXT063 are likewise prohibited.
759 * **`SVP64:{EXT000-063}`** and **`SVP64:{EXT200-263}`** - Full Vectorization
760 of EXT000-063 and EXT200-263 respectively, these Prefixed instructions
761 are likewise prohibited from being a different encoding from their
762 32-bit scalar versions.
764 Limitations of this scheme is that new 32-bit Scalar operations have to have
765 a 32-bit "prefix pattern" in front of them. If commonly-used this could
766 increase binary size. Thus the Encodings EXT300-363 and EXT200-263 should
767 only be allocated for less-popular operations. However the scheme does
768 have the strong advantage of *tripling* the available number of Major
769 Opcodes in the Power ISA, caveat being that care on allocation is needed
770 because EXT200-EXT263 may be SVP64-Augmented whilst EXT300-EXT363 may **not**.
771 The issues of allocation for bitmanip etc. from Libre-SOC is therefore
772 overwhelmingly made moot. The only downside is that there is no
773 `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR).
775 *Most importantly what this scheme does not do is provide large areas
776 for other (non-Vectorizeable) RFCs.*
778 # Potential Opcode allocation solution (2)
780 One of the risks of the bit 6/7 scheme above is that there is no
781 room to share PO9 (EXT009) with other potential uses. A workaround for
784 * EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit
785 encoding. This makes Multi-Issue Length-identification trivial.
786 * bit 6 if 0b1 is 100% for Simple-V augmentation of (Public v3.1 1.6.3)
787 "Defined Word-instructions" (aka EXT000-063), with the exception of 0x26000000
788 as a Prefix, which is a new RESERVED encoding.
789 * when bit 6 is 0b0 and bits 32-33 are 0b11 are **defined** as also
790 allocated to Simple-V
791 * all other patterns are `RESERVED` for other non-Vectorizeable
792 purposes (just over 37.5%).
794 | 0-5 | 6 | 7 | 8-31 | 32:33 | Description |
795 |-----|---|---|-------|-------|----------------------------|
796 | PO9?| 0 | 0 | !zero | 00-10 | RESERVED (other) |
797 | PO9?| 0 | 1 | xxxx | 00-10 | RESERVED (other) |
798 | PO9?| x | 0 | 0000 | xx | RESERVED (other) |
799 | PO9?| 0 | 0 | !zero | 11 | SVP64 (current and future) |
800 | PO9?| 0 | 1 | xxxx | 11 | SVP64 (current and future) |
801 | PO9?| 1 | 0 | !zero | xx | SVP64 (current and future) |
802 | PO9?| 1 | 1 | xxxx | xx | SVP64 (current and future) |
804 This ensures that any potential for future conflict over uses of the
805 EXT009 space, jeapordising Simple-V in the process, are avoided,
806 yet leaves huge areas (just over 37.5% of the 64-bit space) for other
807 (non-Vectorizeable) uses.
809 These areas thus need to be Allocated (SVP64 and Scalar EXT248-263):
811 | 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
812 |-----|---|---|-------|------|---------------------------|
813 | PO | 0 | 0 | !zero | 0b11 | SVP64Single:EXT248-263, or `RESERVED3` |
814 | PO | 0 | 0 | 0000 | 0b11 | Scalar EXT248-263 |
815 | PO | 0 | 1 | nnnn | 0b11 | SVP64:EXT248-263 |
816 | PO | 1 | 0 | !zero | nn | SVP64Single:EXT000-063 or `RESERVED4` |
817 | PO | 1 | 1 | nnnn | nn | SVP64:EXT000-063 |
819 and reserved areas, QTY 1of 32-bit, and QTY 3of 55-bit, are:
821 | 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
822 |-----|---|---|-------|------|---------------------------|
823 | PO9?| 1 | 0 | 0000 | xx | `RESERVED1` or EXT300-363 (32-bit) |
824 | PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 (55-bit) |
825 | PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 (55-bit) |
826 | PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 (55-bit) |
828 * SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
829 (but needs reserving as part of this RFC)
830 * `RESERVED1/2` is available for new general-purpose
831 (non-Vectorizeable) 32-bit encodings (other RFCs)
832 * EXT248-263 is for "new" instructions
833 which **must** be granted corresponding space
835 * Anything Vectorized-EXT000-063 is **automatically** being
836 requested as 100% Reserved for every single "Defined Word-instruction"
837 (Public v3.1 1.6.3 definition). Vectorized-EXT001 or EXT009
838 is defined as illegal.
839 * Any **future** instruction
840 added to EXT000-063 likewise, must **automatically** be
841 assigned corresponding reservations in the SVP64:EXT000-063
842 and SVP64Single:EXT000-063 area, regardless of whether the
843 instruction is Vectorizeable or not.
845 Bit-allocation Summary:
847 * EXT3nn and other areas provide space for up to
848 QTY 4of non-Vectorizeable EXTn00-EXTn47 ranges.
849 * QTY 3of 55-bit spaces also exist for future use (longer by 3 bits
850 than opcodes allocated in EXT001)
851 * Simple-V EXT2nn is restricted to range EXT248-263
852 * non-Simple-V (non-Vectorizeable) EXT2nn (if ever requested in any future RFC) is restricted to range EXT200-247
853 * Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
855 **This however potentially puts SVP64 under pressure (in 5-10 years).**
856 Ideas being discussed already include adding LD/ST-with-Shift and variant
857 Shift-Immediate operations that require large quantity of Primary Opcodes.
858 To ensure that there is room in future,
859 it may be better to allocate 25% to `RESERVED`:
861 | 0-5 | 6 | 7 | 8-31 | 32| Description |
862 |-----|---|---|-------|---|------------------------------------|
863 | PO9?| 1 | 0 | 0000 | x | EXT300-363 or `RESERVED1` (32-bit) |
864 | PO9?| 0 | x | xxxx | 0 | EXT200-232 or `RESERVED2` (56-bit) |
865 | PO9?| 0 | x | xxxx | 1 | EXT232-263 and SVP64(/V/S) |
867 The clear separation between Simple-V and non-Simple-V stops
868 conflict in future RFCs, both of which get plenty of space.
869 EXT000-063 pressure is reduced in both Vectorizeable and
870 non-Vectorizeable, and the 100+ Vectorizeable Scalar operations
871 identified by Libre-SOC may safely be proposed and each evaluated
879 These are Scalar word-encodings. Often termed "v3.0 Scalar" in this document
880 Power ISA v3.1 Section 1.6.3 Book I calls it a "Defined Word-instruction".
884 | PO | EXT000-063 "Defined Word-instruction" |
886 **SVP64Single:{EXT000-063}** bit6=old bit7=scalar
888 This encoding, identical to SVP64Single:{EXT248-263},
889 introduces SVP64Single Augmentation of Scalar "Defined Word-instructions".
890 All meanings must be identical to EXT000-063, and is is likewise
891 prohibited to add an instruction in this area without also adding
892 the exact same (non-Augmented) instruction in EXT000-063 with the
893 exact same Scalar word.
894 Bits 32-37 0b00000 to 0b11111 represent EXT000-063 respectively.
895 Augmenting EXT001 or EXT009 is prohibited.
897 | 0-5 | 6 | 7 | 8-31 | 32-63 |
898 |--------|---|---|-------|---------|
899 | PO (9)?| 1 | 0 | !zero | SVP64Single:{EXT000-063} |
901 **SVP64:{EXT000-063}** bit6=old bit7=vector
903 This encoding is identical to **SVP64:{EXT248-263}** except it
904 is the Vectorization of existing v3.0/3.1 Scalar-words, EXT000-063.
905 All the same rules apply with the addition that
906 Vectorization of EXT001 or EXT009 is prohibited.
908 | 0-5 | 6 | 7 | 8-31 | 32-63 |
909 |--------|---|---|-------|---------|
910 | PO (9)?| 1 | 1 | nnnn | SVP64:{EXT000-063} |
912 **{EXT232-263}** bit6=new bit7=scalar
914 This encoding represents the opportunity to introduce EXT248-263.
915 It is a Scalar-word encoding, and does not require implementing
916 SVP64 or SVP64-Single, but does require the Vector-space to be allocated.
917 PO2 is in the range 0b100000 to 0b1111111 to represent EXT232-263 respectively.
919 | 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
920 |--------|---|---|-------|----|---------|---------|
921 | PO (9)?| 0 | 0 | 0000 | 1 |PO2[1:5] | {EXT232-263} |
923 **SVP64Single:{EXT232-263}** bit6=new bit7=scalar
925 This encoding, which is effectively "implicit VL=1"
926 and comprising (from bits 8-31 being non-zero)
927 *at least some* form of Augmentation, it represents the opportunity
928 to Augment EXT232-263 with the SVP64Single capabilities.
929 Must be allocated under Scalar *and* SVP64 simultaneously.
931 | 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
932 |--------|---|---|-------|----|---------|---------|
933 | PO (9)?| 0 | 0 | !zero | 1 |PO2[1:5] | SVP64Single:{EXT232-263} |
935 **SVP64:{EXT248-263}** bit6=new bit7=vector
937 This encoding, which permits VL to be dynamic (settable from GPR or CTR)
938 is the Vectorization of EXT248-263.
939 Instructions may not be placed in this category without also being
940 implemented as pure Scalar *and* SVP64Single. Unlike SVP64Single
941 however, there is **no reserved encoding** (bits 8-24 zero).
942 VL=1 may occur dynamically
943 at runtime, even when bits 8-31 are zero.
945 | 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
946 |--------|---|---|-------|----|---------|---------|
947 | PO (9)?| 0 | 1 | nnnn | 1 |PO2[1:5] | SVP64:{EXT232-263} |
949 **RESERVED1 / EXT300-363** bit6=old bit7=scalar
951 This is at the discretion of the ISA WG. Libre-SOC is *not*
952 proposing the addition of EXT300-363: it is merely a possibility
954 | 0-5 | 6 | 7 | 8-31 | 32-63 |
955 |--------|---|---|-------|---------|
956 | PO (9)?| 1 | 0 | 0000 | EXT300-363 or `RESERVED1` |
958 **RESERVED2 / EXT200-231** bit6=new bit32=1
960 This is at the discretion of the ISA WG. Libre-SOC is *not*
961 proposing the addition of EXT200-231: it is merely a possibility
963 | 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
964 |--------|---|---|-------|----|---------|---------|
965 | PO (9)?| 0 | x | nnnn | 1 |PO2[1:5] | {EXT200-231} |
968 # Example Legal Encodings and RESERVED spaces
970 This section illustrates what is legal encoding, what is not, and
971 why the 4 spaces should be `RESERVED` even if not allocated as part
974 **legal, scalar and vector**
976 | width | assembler | prefix? | suffix | description |
977 |-------|-----------|--------------|-----------|---------------|
978 | 32bit | fishmv | none | 0x12345678| scalar EXT0nn |
979 | 64bit | ss.fishmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
980 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
984 | width | assembler | prefix? | suffix | description |
985 |-------|-----------|--------------|-----------|---------------|
986 | 64bit | fishmv | 0x24000000 | 0x12345678| scalar EXT2nn |
987 | 64bit | ss.fishmv | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
988 | 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
990 Here the encodings are the same, 0x12345678 means the same thing in
991 all cases. Anything other than this risks either damage (truncation
992 of capabilities of Simple-V) or far greater complexity in the
995 This drives the compromise proposal (above) to reserve certain
998 (in the Scalar Suffix side, irrespective of Prefix), some allocated
999 to Simple-V, some not.
1001 **illegal due to missing**
1003 | width | assembler | prefix? | suffix | description |
1004 |-------|-----------|--------------|-----------|---------------|
1005 | 32bit | fishmv | none | 0x12345678| scalar EXT0nn |
1006 | 64bit | ss.fishmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
1007 | 64bit | unallocated | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
1009 This is illegal because the instruction is possible to Vectorize,
1010 therefore it should be **defined** as Vectorizeable.
1012 **illegal due to unvectorizeable**
1014 | width | assembler | prefix? | suffix | description |
1015 |-------|-----------|--------------|-----------|---------------|
1016 | 32bit | mtmsr | none | 0x12345678| scalar EXT0nn |
1017 | 64bit | ss.mtmsr | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
1018 | 64bit | sv.mtmsr | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
1020 This is illegal because the instruction `mtmsr` is not possible to Vectorize,
1021 at all. This does **not** convey an opportunity to allocate the
1022 space to an alternative instruction.
1024 **illegal unvectorizeable in EXT2nn**
1026 | width | assembler | prefix? | suffix | description |
1027 |-------|-----------|--------------|-----------|---------------|
1028 | 64bit | mtmsr2 | 0x24000000 | 0x12345678| scalar EXT2nn |
1029 | 64bit | ss.mtmsr2 | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
1030 | 64bit | sv.mtmsr2 | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
1032 For a given hypothetical `mtmsr2` which is inherently Unvectorizeable
1033 whilst it may be put into the scalar EXT2nn space it may **not** be
1034 allocated in the Vector space. As with Unvectorizeable EXT0nn opcodes
1035 this does not convey the right to use the 0x24/0x26 space for alternative
1036 opcodes. This hypothetical Unvectorizeable operation would be better off
1037 being allocated as EXT001 Prefixed, EXT000-063, or hypothetically in
1040 **ILLEGAL: dual allocation**
1042 | width | assembler | prefix? | suffix | description |
1043 |-------|-----------|--------------|-----------|---------------|
1044 | 32bit | fredmv | none | 0x12345678| scalar EXT0nn |
1045 | 64bit | ss.fredmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
1046 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
1048 the use of 0x12345678 for fredmv in scalar but fishmv in Vector is
1049 illegal. the suffix in both 64-bit locations
1050 must be allocated to a Vectorizeable EXT000-063
1051 "Defined Word-instruction" (Public v3.1 Section 1.6.3 definition)
1056 **illegal unallocated scalar EXT0nn or EXT2nn:**
1058 | width | assembler | prefix? | suffix | description |
1059 |-------|-----------|--------------|-----------|---------------|
1060 | 32bit | unallocated | none | 0x12345678| scalar EXT0nn |
1061 | 64bit | ss.fredmv | 0x26!zero | 0x12345678| scalar SVP64Single:EXT0nn |
1062 | 64bit | sv.fishmv | 0x27nnnnnn | 0x12345678| vector SVP64:EXT0nn |
1066 | width | assembler | prefix? | suffix | description |
1067 |-------|-----------|--------------|-----------|---------------|
1068 | 64bit | unallocated | 0x24000000 | 0x12345678| scalar EXT2nn |
1069 | 64bit | ss.fishmv | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
1070 | 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
1072 Both of these Simple-V operations are illegally-allocated. The fact that
1073 there does not exist a scalar "Defined Word-instruction" (even for EXT200-263) - the
1074 unallocated block - means that the instruction may **not** be allocated in
1077 **illegal attempt to put Scalar EXT004 into Vector EXT2nn**
1079 | width | assembler | prefix? | suffix | description |
1080 |-------|-----------|--------------|-----------|---------------|
1081 | 32bit | unallocated | none | 0x10345678| scalar EXT0nn |
1082 | 64bit | ss.fishmv | 0x24!zero | 0x10345678| scalar SVP64Single:EXT2nn |
1083 | 64bit | sv.fishmv | 0x25nnnnnn | 0x10345678| vector SVP64:EXT2nn |
1085 This is an illegal attempt to place an EXT004 "Defined Word-instruction"
1086 (Public v3.1 Section 1.6.3) into the EXT2nn Vector space.
1087 This is not just illegal it is not even possible to achieve.
1088 If attempted, by dropping EXT004 into bits 32-37, the top two
1089 MSBs are actually *zero*, and the Vector EXT2nn space is only
1090 legal for Primary Opcodes in the range 232-263, where the top
1091 two MSBs are 0b11. Thus this faulty attempt actually falls
1093 into `RESERVED` "Non-Vectorizeable" Encoding space.
1095 **illegal attempt to put Scalar EXT001 into Vector space**
1097 | width | assembler | prefix? | suffix | description |
1098 |-------|-----------|--------------|-----------|---------------|
1099 | 64bit | EXT001 | 0x04nnnnnn | any | scalar EXT001 |
1100 | 96bit | sv.EXT001 | 0x24!zero | EXT001 | scalar SVP64Single:EXT001 |
1101 | 96bit | sv.EXT001 | 0x25nnnnnn | EXT001 | vector SVP64:EXT001 |
1103 This becomes in effect an effort to define 96-bit instructions,
1104 which are illegal due to cost at the Decode Phase (Variable-Length
1105 Encoding). Likewise attempting to embed EXT009 (chained) is also
1106 illegal. The implications are clear unfortunately that all 64-bit
1107 EXT001 Scalar instructions are Unvectorizeable.
1112 In the following examples the programs are fully executable under the
1113 Libre-SOC Simple-V-augmented Power ISA Simulator. Reproducible
1114 (scripted) Installation instructions:
1115 <https://libre-soc.org/HDL_workflow/devscripts/>
1119 Context-switching saving and restoring of registers on the stack often
1120 requires explicit loop-unrolling to achieve effectively. In SVP64 it
1121 is possible to use a Predicate Mask to "compact" or "expand" a swathe
1122 of desired registers, dynamically. Known as "VCOMPRESS" and "VEXPAND",
1123 runtime-configurable LD/ST-Multi is achievable with 2 instructions.
1126 # load 64 registers off the stack, in-order, skipping unneeded ones
1127 # by using CR0-CR63's "EQ" bits to select only those needed.
1129 sv.ld/sm=EQ *rt,0(ra)
1132 ## Twin-Predication, re-entrant
1134 This example demonstrates two key concepts: firstly Twin-Predication
1135 (separate source predicate mask from destination predicate mask) and
1136 that sufficient state is stored within the Vector Context SPR, SVSTATE,
1137 for full re-entrancy on a Context Switch or function call *even if
1138 in the middle of executing a loop*. Also demonstrates that it is
1139 permissible for a programmer to write **directly** to the SVSTATE
1140 SPR, and still expect Deterministic Behaviour. It's not exactly recommended
1141 (performance may be impacted by direct SVSTATE access), but it is not
1145 292 # checks that we are able to resume in the middle of a VL loop,
1146 293 # after an interrupt, or after the user has updated src/dst step
1147 294 # let's assume the user has prepared src/dst step before running this
1148 295 # vector instruction
1149 296 # test_intpred_reentrant
1150 297 # reg num 0 1 2 3 4 5 6 7 8 9 10 11 12
1152 299 # src r3=0b0101 Y N Y N
1157 304 # dest ~r3=0b1010 N Y N Y
1160 307 sv.extsb/sm=r3/dm=~r3 *5, *9
1163 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_predication.py;hb=HEAD>
1167 Matrix Multiply of any size (non-power-2) up to a total of 127 operations
1168 is achievable with only three instructions. Normally in any other SIMD
1169 ISA at least one source requires Transposition and often massive rolling
1170 repetition of data is required. These 3 instructions may be used as the
1171 "inner triple-loop kernel" of the usual 6-loop Massive Matrix Multiply.
1174 28 # test_sv_remap1 5x4 by 4x3 matrix multiply
1175 29 svshape 5, 4, 3, 0, 0
1176 30 svremap 31, 1, 2, 3, 0, 0, 0
1177 31 sv.fmadds *0, *8, *16, *0
1180 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;hb=HEAD>
1182 ## Parallel Reduction
1184 Parallel (Horizontal) Reduction is often deeply problematic in SIMD and
1185 Vector ISAs. Parallel Reduction is Fully Deterministic in Simple-V and
1186 thus may even usefully be deployed on non-associative and non-commutative
1191 76 svshape 7, 0, 0, 7, 0
1192 77 svremap 31, 1, 0, 0, 0, 0, 0 # different order
1193 78 sv.subf *0, *8, *16
1196 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_parallel_reduce.py;hb=HEAD>
1201 DCT has dozens of uses in Audio-Visual processing and CODECs.
1202 A full 8-wide in-place triple-loop Inverse DCT may be achieved
1203 in 8 instructions. Expanding this to 16-wide is a matter of setting
1204 `svshape 16` **and the same instructions used**.
1205 Lee Composition may be deployed to construct non-power-two DCTs.
1206 The cosine table may be computed (once) with 18 Vector instructions
1207 (one of them `fcos`)
1210 1014 # test_sv_remap_fpmadds_ldbrev_idct_8_mode_4
1211 1015 # LOAD bit-reversed with half-swap
1212 1016 svshape 8, 1, 1, 14, 0
1213 1017 svremap 1, 0, 0, 0, 0, 0, 0
1214 1018 sv.lfs/els *0, 4(1)
1215 1019 # Outer butterfly, iterative sum
1216 1020 svremap 31, 0, 1, 2, 1, 0, 1
1217 1021 svshape 8, 1, 1, 11, 0
1218 1022 sv.fadds *0, *0, *0
1219 1023 # Inner butterfly, twin +/- MUL-ADD-SUB
1220 1024 svshape 8, 1, 1, 10, 0
1221 1025 sv.ffmadds *0, *0, *0, *8
1224 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;hb=HEAD>
1226 ## 3D GPU style "Branch Conditional"
1228 (*Note: Specification is ready, Simulator still under development of
1229 full specification capabilities*)
1230 This example demonstrates a 2-long Vector Branch-Conditional only
1231 succeeding if *all* elements in the Vector are successful. This
1232 avoids the need for additional instructions that would need to
1233 perform a Parallel Reduction of a Vector of Condition Register
1234 tests down to a single value, on which a Scalar Branch-Conditional
1235 could then be performed. Full Rationale at
1236 <https://libre-soc.org/openpower/sv/branches/>
1239 80 # test_sv_branch_cond_all
1240 81 for i in [7, 8, 9]:
1241 83 addi 1, 0, i+1 # set r1 to i
1242 84 addi 2, 0, i # set r2 to i
1243 85 cmpi cr0, 1, 1, 8 # compare r1 with 8 and store to cr0
1244 86 cmpi cr1, 1, 2, 8 # compare r2 with 8 and store to cr1
1245 87 sv.bc/all 12, *1, 0xc # bgt 0xc - branch if BOTH
1246 88 # r1 AND r2 greater 8 to the nop below
1247 89 addi 3, 0, 0x1234, # if tests fail this shouldn't execute
1248 90 or 0, 0, 0 # branch target
1251 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bc.py;hb=HEAD>
1255 Remarkably, `sv.adde` is inherently a big-integer Vector Add, using `CA`
1256 chaining between **Scalar** operations.
1257 Using Vector LD/ST and recalling that the first and last `CA` may
1258 be chained in and out of an entire **Vector**, unlimited-length arithmetic is
1262 26 # test_sv_bigint_add
1264 33 r3/r2: 0x0000_0000_0000_0001 0xffff_ffff_ffff_ffff +
1265 34 r5/r4: 0x8000_0000_0000_0000 0x0000_0000_0000_0001 =
1266 35 r1/r0: 0x8000_0000_0000_0002 0x0000_0000_0000_0000
1268 37 sv.adde *0, *2, *4
1271 A 128/64-bit shift may be used as a Vector shift by a Scalar amount, by merging
1272 two 64-bit consecutive registers in succession.
1275 62 # test_sv_bigint_scalar_shiftright(self):
1278 66 0x0000_0000_0000_0002 0x8000_8000_8000_8001 0xffff_ffff_ffff_ffff >> 4
1279 67 0x0000_0000_0000_0002 0x2800_0800_0800_0800 0x1fff_ffff_ffff_ffff
1281 69 sv.dsrd *0,*1,4,1
1284 Additional 128/64 Mul and Div/Mod instructions may similarly be exploited
1285 to perform roll-over in arbitrary-length arithmetic: effectively they use
1286 one of the two 64-bit output registers as a form of "64-bit Carry In-Out".
1288 All of these big-integer instructions are Scalar instructions standing on
1289 their own merit and may be utilised even in a Scalar environment to improve
1290 performance. When used with Simple-V they may also be used to improve
1291 performance and also greatly simplify unlimited-length biginteger algorithms.
1293 <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bigint.py;hb=HEAD>
1296 # Vectorized strncpy
1298 Aside from the `blr` return instruction this is an entire fully-functional
1299 implementation of `strncpy` which demonstrates some of the remarkably
1300 powerful capabilities of Simple-V. Load Fault-First avoids instruction
1301 traps and page faults in the middle of the Vectorized Load, providing
1302 the *micro-architecture* with the opportunity to notify the program of
1303 the successful Vector Length. `sv.cmpi` is the next strategically-critical
1304 instruction, as it searches for a zero and yet *includes* it in a new
1305 Vector Length - bearing in mind that the previous instruction (the Load)
1306 *also* truncated down to the valid number of LDs performed. Finally,
1307 a Vectorized Branch-Conditional automatically decrements CTR by the number
1308 of elements copied (VL), rather than decrementing simply by one.
1311 41 "mtspr 9, 3", # move r3 to CTR
1312 42 "addi 0,0,0", # initialise r0 to zero
1313 43 # chr-copy loop starts here:
1314 44 # for (i = 0; i < n && src[i] != '\0'; i++)
1315 45 # dest[i] = src[i];
1316 46 # VL (and r1) = MIN(CTR,MAXVL=4)
1317 47 "setvl 1,0,%d,0,1,1" % maxvl,
1318 48 # load VL bytes (update r10 addr)
1319 49 "sv.lbzu/pi *16, 1(10)",
1320 50 "sv.cmpi/ff=eq/vli *0,1,*16,0", # compare against zero, truncate VL
1321 51 # store VL bytes (update r12 addr)
1322 52 "sv.stbu/pi *16, 1(12)",
1323 53 "sv.bc/all 0, *2, -0x1c", # test CTR, stop if cmpi failed
1324 54 # zeroing loop starts here:
1325 55 # for ( ; i < n; i++)
1326 56 # dest[i] = '\0';
1327 57 # VL (and r1) = MIN(CTR,MAXVL=4)
1328 58 "setvl 1,0,%d,0,1,1" % maxvl,
1329 59 # store VL zeros (update r12 addr)
1330 60 "sv.stbu/pi 0, 1(12)",
1331 61 "sv.bc 16, *0, -0xc", # decrement CTR by VL, stop at zero
1334 [[!inline pages="openpower/sv/po9_encoding" raw=yes ]]
1338 [^zolc]: first introduced in DSPs, Zero-Overhead Loops are astoundingly effective in reducing total number of instructions executed or needed. [ZOLC](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.301.4646&rep=rep1&type=pdf) reduces instructions by **25 to 80 percent**.
1339 [^msr]: an MSR bit or bits, conceptually equivalent to `MSR.SF` and added for the same reasons, would suffice perfectly.
1340 [^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
1341 [^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.
1342 [^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
1343 [^only2]: reminder that this proposal only needs 75% of two POs for Scalar instructions. The rest of EXT200-263 is for general use.
1344 [^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-instruction" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively
1345 [^futurevsx]: A future version or other Stakeholder *may* wish to drop Simple-V onto VSX: this would be a separate RFC
1346 [^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.
1347 [^autovec]: Compiler auto-vectorization 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.
1348 [^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
1349 [^svshape]: although SVSHAPE0-3 should, realistically, be regarded as high a priority as SVSTATE, and given corresponding SVSRR and SVLR equivalents, it was felt that having to context-switch **five** SPRs on Interrupts and function calls was too much.
1350 [^whoops]: two efforts were made to mix non-uniform encodings into Simple-V space: one deliberate to see how it would go, and one accidental. They both went extremely badly, the deliberate one costing over two months to add then remove.
1351 [^mul]: Setting this "multiplier" to 1 clearly leaves pre-existing Scalar behaviour completely intact as a degenerate case.
1352 [^ldstcisc]: At least the CISC "auto-increment" modes are not present, from the CDC 6600 and Motorola 68000! although these would be fun to introduce they do unfortunately make for 3-in 3-out register profiles, all 64-bit, which explains why the 6600 and 68000 had separate special dedicated address regfiles.