5 <img src="https://assets.amuniversal.com/7fada35026ca01393d3d005056a9545d" width="600" />
9 * <https://bugs.libre-soc.org/show_bug.cgi?id=213>
10 * <https://youtu.be/ZQ5hw9AwO1U> walkthrough video (19jun2022)
11 * <https://ftp.libre-soc.org/simple_v_spec.pdf>
12 PDF version of this DRAFT specification
14 **SV is in DRAFT STATUS**. SV has not yet been submitted to the OpenPOWER Foundation ISA WG for review.
18 # Scalable Vectors for the Power ISA
20 SV is designed as a strict RISC-paradigm
21 Scalable Vector ISA for Hybrid 3D CPU GPU VPU workloads.
22 As such it brings features normally only found in Cray Supercomputers
23 (Cray-1, NEC SX-Aurora)
24 and in GPUs, but keeps strictly to a *Simple* RISC principle of leveraging
25 a *Scalar* ISA, exclusively using "Prefixing". **Not one single actual
26 explicit Vector opcode exists in SV, at all**. It is suitable for
27 low-power Embedded and DSP Workloads as much as it is for power-efficient
30 Fundamental design principles:
32 * Taking the simplicity of the RISC paradigm and applying it strictly and
33 uniformly to create a Scalable Vector ISA.
34 * Effectively a hardware for-loop, pausing PC, issuing multiple scalar
36 * Preserving the underlying scalar execution dependencies as if the
37 for-loop had been expanded as actual scalar instructions
38 (termed "preserving Program Order")
39 * Augments ("tags") existing instructions, providing Vectorisation
40 "context" rather than adding new instructions.
41 * Strictly does not interfere with or alter the non-Scalable Power ISA
43 * In the Prefix space, does not modify or deviate from the underlying
45 unless it provides significant performance or other advantage to do so
46 in the Vector space (dropping the "sticky" characteristics
47 of XER.SO and CR0.SO for example)
48 * Designed for Supercomputing: avoids creating significant sequential
49 dependency hazards, allowing standard
50 high performance superscalar multi-issue
51 micro-architectures to be leveraged.
52 * Divided into Compliancy Levels to reduce cost of implementation for
55 Advantages of these design principles:
57 * Simplicity of introduction and implementation on top of
58 the existing Power ISA without disruption.
59 * It is therefore easy to create a first (and sometimes only)
60 implementation as literally a for-loop in hardware, simulators, and
62 * Hardware Architects may understand and implement SV as being an
63 extra pipeline stage, inserted between decode and issue, that is
64 a simple for-loop issuing element-level sub-instructions.
65 * More complex HDL can be done by repeating existing scalar ALUs and
66 pipelines as blocks and leveraging existing Multi-Issue Infrastructure
67 * As (mostly) a high-level "context" that does not (significantly) deviate
68 from scalar Power ISA and, in its purest form being "a for loop around
69 scalar instructions", it is minimally-disruptive and consequently stands
70 a reasonable chance of broad community adoption and acceptance
71 * Completely wipes not just SIMD opcode proliferation off the
72 map (SIMD is O(N^6) opcode proliferation)
73 but off of Vectorisation ISAs as well. No more separate Vector
76 Comparative instruction count:
78 * ARM NEON SIMD: around 2,000 instructions, prerequisite: ARM Scalar.
79 * ARM SVE: around 4,000 instructions, prerequisite: NEON and ARM Scalar
80 * ARM SVE2: around 1,000 instructions, prerequisite: SVE, NEON, and
82 * Intel AVX-512: around 4,000 instructions, prerequisite AVX, AVX2,
83 AVX-128 and AVX-256 which in turn critically rely on the rest of
84 x86, for a grand total of well over 10,000 instructions.
85 * RISV-V RVV: 192 instructions, prerequisite 96 Scalar RV64GC instructions
86 * SVP64: **five** instructions, 24-bit prefixing of
87 prerequisite SFS (150) or
88 SFFS (214) Compliancy Subsets
90 SV comprises several [[sv/compliancy_levels]] suited to Embedded, Energy
91 efficient High-Performance Compute, Distributed Computing and Advanced
92 Computational Supercomputing. The Compliancy Levels are arranged such
93 that even at the bare minimum Level, full Soft-Emulation of all
94 optional and future features is possible.
98 Pages being developed and examples
100 * [[sv/executive_summary]]
101 * [[sv/overview]] explaining the basics.
102 * [[sv/compliancy_levels]] for minimum subsets through to Advanced
104 * [[sv/implementation]] implementation planning and coordination
105 * [[sv/svp64]] contains the packet-format *only*, the [[svp64/appendix]]
106 contains explanations and further details
107 * [[sv/svp64_quirks]] things in SVP64 that slightly break the rules
108 or are not immediately apparent despite the RISC paradigm
109 * [[opcode_regs_deduped]] autogenerated table of SVP64 decoder augmentation
114 * For condition register operations see [[sv/cr_ops]] - SVP64 Condition
115 Register ops: Guidelines
116 on Vectorisation of any v3.0B base operations which return
117 or modify a Condition Register bit or field.
118 * For LD/ST Modes, see [[sv/ldst]].
119 * For Branch modes, see [[sv/branches]] - SVP64 Conditional Branch
120 behaviour: All/Some Vector CRs
121 * For arithmetic and logical, see [[sv/normal]]
122 * [[sv/mv.vec]] pack/unpack move to and from vec2/3/4,
123 actually an RM.EXTRA Mode and a [[sv/remap]] mode
125 Core SVP64 instructions:
127 * [[sv/setvl]] the Cray-style "Vector Length" instruction
128 * svremap, svindex and svshape: part of [[sv/remap]] "Remapping" for
129 Matrix Multiply, DCT/FFT and RGB-style "Structure Packing"
130 as well as general-purpose Indexing. Also describes associated SPRs.
131 * [[sv/svstep]] Key stepping instruction, primarily for
132 Vertical-First Mode and also providing traditional "Vector Iota"
135 *Please note: there are only five instructions in the whole of SV.
136 Beyond this point are additional **Scalar** instructions related to
137 specific workloads that have nothing to do with the SV Specification*
139 # Optional Scalar instructions
141 **Additional Instructions for specific purposes (not SVP64)**
143 All of these instructions below have nothing to do with SV.
144 They are all entirely designed as Scalar instructions that, as
145 Scalar instructions, stand on their own merit. Considerable
146 lengths have been made to provide justifications for each of these
147 *Scalar* instructions in a *Scalar* context, completely independently
150 Some of these Scalar instructions happen also designed to make
151 Scalable Vector binaries more efficient, such
152 as the crweird group. Others are to bring the Scalar Power ISA
153 up-to-date within specific workloads,
154 such as a Javascript Rounding instruction
155 (which saves 35 instructions including 5 branches). None of them are strictly
156 necessary but performance and power consumption may be (or, is already)
158 in certain workloads and use-cases without them.
160 Vector-related but still Scalar:
162 * [[sv/mv.swizzle]] vec2/3/4 Swizzles (RGBA, XYZW) for 3D and CUDA.
163 designed as a Scalar instruction.
164 * [[sv/vector_ops]] scalar operations needed for supporting vectors
165 * [[sv/cr_int_predication]] scalar instructions needed for
166 effective predication
168 Stand-alone Scalar Instructions:
171 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
172 * [[sv/fclass]] detect class of FP numbers
173 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
174 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
175 * TODO: OpenPOWER adaptation [[openpower/transcendentals]]
177 Twin targetted instructions (two registers out, one implicit, just like
180 * [[isa/svfixedarith]]
182 * [[sv/biginteger]] Operations that help with big arithmetic
184 Explanation of the rules for twin register targets
185 (implicit RS, FRS) explained in SVP64 [[svp64/appendix]]
187 # Other Scalable Vector ISAs
189 These Scalable Vector ISAs are listed to aid in understanding and
190 context of what is involved.
193 <http://www.bitsavers.org/pdf/cray/CRAY_Y-MP/HR-04001-0C_Cray_Y-MP_Computer_Systems_Functional_Description_Jun90.pdf>
194 * NEC SX Aurora (still in production, inspired by Cray)
195 <https://www.hpc.nec/documents/guide/pdfs/Aurora_ISA_guide.pdf>
196 * RISC-V RVV (inspired by Cray)
197 <https://github.com/riscv/riscv-v-spec>
198 * MRISC32 ISA Manual (under active development)
199 <https://github.com/mrisc32/mrisc32/tree/master/isa-manual>
200 * Mitch Alsup's MyISA 66000 Vector Processor ISA Manual is available from
203 A comprehensive list of 3D GPU, Packed SIMD, Predicated-SIMD and true Scalable
204 Vector ISAs may be found at the [[sv/vector_isa_comparison]] page.
205 Note: AVX-512 and SVE2 are *not Vector ISAs*, they are Predicated-SIMD.
206 *Public discussions have taken place at Conferences attended by both Intel
207 and ARM on adding a `setvl` instruction which would easily make both
208 AVX-512 and SVE2 truly "Scalable".* [[sv/comparison_table]] in tabular
211 # Major opcodes summary
213 Simple-V itself only requires five instructions with 6-bit Minor XO
214 (bits 26-31), and the SVP64 Prefix Encoding requires
215 25% space of the EXT001 Major Opcode.
216 There are **no** Vector Instructions and consequently **no further
217 opcode space is required**. Even though they are currently
218 placed in the EXT022 Sandbox, the "Management" instructions
219 (setvl, svstep, svremap, svshape, svindex) are designed to fit
220 cleanly into EXT019 (exactly like `addpcis`) or other 5/6-bit Minor
221 XO area (bits 25-31) that has space for Rc=1.
223 That said: for the target workloads for which Scalable Vectors are typically
224 used, the Scalar ISA on which those workloads critically rely
226 The Libre-SOC Team has therefore been addressing that by developing
227 a number of Scalar instructions in specialist areas (Big Integer,
228 Cryptography, 3D, Audio/Video, DSP) and it is these which require
229 considerable Scalar opcode space.
231 Please be advised that even though SV is entirely DRAFT status, there
232 is considerable concern that because there is not yet any two-way
233 day-to-day communication established with the OPF ISA WG, we have
234 no idea if any of these are conflicting with future plans by any OPF
235 Members. **The External ISA WG RFC Process is yet to be ratified
236 and Libre-SOC may not join the OPF as an entity because it does
237 not exist except in name. Even if it existed it would be a conflict
238 of interest to join the OPF, due to our funding remit from NLnet**.
239 We therefore proceed on the basis of making public the intention to
240 submit RFCs once the External ISA WG RFC Process is in place and,
241 in a wholly unsatisfactory manner have to *hope and trust* that
242 OPF ISA WG Members are reading this and take it into consideration.
246 As in above sections, it is emphasised strongly that Simple-V in no
247 way critically depends on the 100 or so *Scalar* instructions also
248 being developed by Libre-SOC.
250 **None of these Draft opcodes are intended for private custom
251 secret proprietary usage. They are all intended for entirely
252 public, upstream, high-profile mass-volume day-to-day usage at the
253 same level as add, popcnt and fld**
255 * bitmanip requires two major opcodes (due to 16+ bit immediates)
256 those are currently EXT022 and EXT05.
257 * brownfield encoding in one of those two major opcodes still
258 requires multiple VA-Form operations (in greater numbers
259 than EXT04 has spare)
260 * space in EXT019 next to addpcis and crops is recommended
261 (or any other 5-6 bit Minor XO areas)
262 * many X-Form opcodes currently in EXT022 have no preference
263 for a location at all, and may be moved to EXT059, EXT019,
264 EXT031 or other much more suitable location.
265 * even if ratified and even if the majority (mostly X-Form)
266 is moved to other locations, the large immediate sizes of
267 the remaining bitmanip instructions means
268 it would be highly likely these remaining instructions would need two
269 major opcodes. Fortuitously the v3.1 Spec states that
270 both EXT005 and EXT009 are
273 **Additional observations**
275 Note that there is no Sandbox allocation in the published ISA Spec for
276 v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
277 Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
278 would become a whopping 96-bit long instruction. Avoiding this
279 situation is a high priority which in turn by necessity puts pressure
280 on the 32-bit Major Opcode space.
282 SVP64 itself is already under pressure, being only 24 bits. If it is
283 not permitted to take up 25% of EXT001 then it would have to be proposed
284 in its own Major Opcode, which on first consideration would be beneficial
285 for SVP64 due to the availability of 2 extra bits.
286 However when combined with the bitmanip scalar instructions
287 requiring two Major opcodes this would come to a grand total of 3 precious
288 Major opcodes. On balance, then, sacrificing 25% of EXT001 is the "least
291 Note also that EXT022, the Official Architectural Sandbox area
292 available for "Custom non-approved purposes" according to the Power
294 is under severe design pressure as it is insufficient to hold
295 the full extent of the instruction additions required to create
296 a Hybrid 3D CPU-VPU-GPU. Akthough the wording of the Power ISA
297 Specification leaves open the *possibility* of not needing to
298 propose ISA Extensions to the ISA WG, it is clear that EXT022
299 is an inappropriate location for a large high-profile Extension
300 intended for mass-volume product deployment. Every in-good-faith effort will
301 therefore be made to work with the OPF ISA WG to
302 submit SVP64 via the External RFC Process.
304 **Whilst SVP64 is only 5 instructions
305 the heavy focus on VSX for the past 12 years has left the SFFS Level
306 anaemic and out-of-date compared to ARM and x86.**
308 a blessing, as the Scalar ISA has remained clean, making it
309 highly suited to RISC-paradigm Scalable Vector Prefixing. Approximately
310 100 additional (optional) Scalar Instructions are up for proposal to bring SFFS
311 up-to-date. None of them require or depend on PackedSIMD VSX (or VMX).
315 Examples experiments future ideas discussion:
317 * [Scalar register access](https://bugs.libre-soc.org/show_bug.cgi?id=905)
319 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
320 * [[sv/masked_vector_chaining]]
322 * [[sv/example_dep_matrices]]
323 * [[sv/major_opcode_allocation]]
325 * [[sv/16_bit_compressed]] experimental
326 * [[sv/toc_data_pointer]] experimental
327 * [[sv/predication]] discussion on predication concepts
328 * [[sv/register_type_tags]]
329 * [[sv/mv.x]] deprecated in favour of Indexed REMAP
333 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
334 * [[sv/vector_isa_comparison]] - a list of Packed SIMD, GPU,
335 and other Scalable Vector ISAs
336 * [[sv/comparison_table]] - a one-off (experimental) table comparing ISAs
337 * [[simple_v_extension]] old (deprecated) version
338 * [[openpower/sv/llvm]]