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