openpower/sv.mdwn

   1 [[!tag standards]]
   2
   3 Obligatory Dilbert:
   4
   5 <img src="https://assets.amuniversal.com/7fada35026ca01393d3d005056a9545d" width="600" />
   6
   7 ===
   8
   9 # SV (Simple Scalar Vectorisation) for the Power ISA
  10
  11 **SV is in DRAFT STATUS**. SV has not yet been submitted to the OpenPOWER Foundation ISA WG for review.
  12
  13 <https://bugs.libre-soc.org/show_bug.cgi?id=213>
  14
  15 SV is designed as a Scalable Vector ISA for Hybrid 3D CPU GPU VPU workloads.
  16 As such it brings features normally only found in Cray Supercomputers
  17 (Cray-1, NEC SX-Aurora)
  18 and in GPUs, but keeps strictly to a *Simple* RISC principle of leveraging
  19 a *Scalar* ISA, exclusively using "Prefixing". **Not one single actual
  20 explicit Vector opcode exists in SV, at all**.
  21
  22 Fundamental design principles:
  23
  24 * Simplicity of introduction and implementation on the existing Power ISA
  25 * Effectively a hardware for-loop, pausing PC, issuing multiple scalar
  26   operations
  27 * Preserving the underlying scalar execution dependencies as if the
  28   for-loop had been expanded as actual scalar instructions
  29   (termed "preserving Program Order")
  30 * Augments ("tags") existing instructions, providing Vectorisation
  31   "context" rather than adding new instructions.
  32 * Does not modify or deviate from the underlying scalar Power ISA
  33   unless it provides significant performance or other advantage to do so
  34   in the Vector space (dropping "sticky" of XER.SO for example)
  35 * Designed for Supercomputing: avoids creating significant sequential
  36   dependency hazards, allowing standard
  37   high performance superscalar multi-issue
  38   micro-architectures to be leveraged.
  39
  40 Advantages of these design principles:
  41
  42 * It is therefore easy to create a first (and sometimes only)
  43   implementation as literally a for-loop in hardware, simulators, and
  44   compilers.
  45 * Hardware Architects may understand and implement SV as being an
  46   extra pipeline stage, inserted between decode and issue, that is
  47   a simple for-loop issuing element-level sub-instructions.
  48 * More complex HDL can be done by repeating existing scalar ALUs and
  49   pipelines as blocks and leveraging existing Multi-Issue Infrastructure
  50 * As (mostly) a high-level "context" that does not (significantly) deviate
  51   from scalar Power ISA and, in its purest form being "a for loop around
  52   scalar instructions", it is minimally-disruptive and consequently stands
  53   a reasonable chance of broad community adoption and acceptance
  54 * Completely wipes not just SIMD opcode proliferation off the
  55   map (SIMD is O(N^6) opcode proliferation)
  56   but off of Vectorisation ISAs as well.  No more separate Vector
  57   instructions.
  58
  59 Comparative instruction count:
  60
  61 * ARM NEON SIMD: around 2,000 instructions, prerequisite: ARM Scalar.
  62 * ARM SVE: around 4,000 instructions, prerequisite: NEON.
  63 * ARM SVE2: around 1,000 instructions, prerequisite: SVE
  64 * Intel AVX-512: around 4,000 instructions, prerequisite AVX2 etc.
  65 * RISV-V RVV: 192 instructions, prerequisite 96 Scalar RV64GC instructions
  66 * SVP64: **four** instructions, 24-bit prefixing of
  67   prerequisite SFS (150) or
  68   SFFS (214) Compliancy Subsets
  69
  70 SV comprises several [[sv/compliancy_levels]] suited to Embedded, Energy
  71 efficient High-Performance Compute, Distributed Computing and Advanced
  72 Computational Supercomputing.  The Compliancy Levels are arranged such
  73 that even at the bare minimum Level, full Soft-Emulation of all
  74 optional and future features is possible.
  75
  76 # Major opcodes summary
  77
  78 Please be advised that even though below is entirely DRAFT status, there
  79 is considerable concern that because there is not yet any two-way
  80 day-to-day communication established with the OPF ISA WG, we have
  81 no idea if any of these are conflicting with future plans by any OPF
  82 Members.  **The External ISA WG RFC Process is yet to be ratified
  83 and Libre-SOC may not join the OPF as an entity because it does
  84 not exist except in name. Even if it existed it would be a conflict
  85 of interest to join the OPF, due to our funding remit from NLnet**.
  86 We therefore proceed on the basis of making public the intention to
  87 submit RFCs once the External ISA WG RFC Process is in place and,
  88 in a wholly unsatisfactory manner have to *hope and trust* that
  89 OPF ISA WG Members are reading this and take it into consideration.
  90
  91 **None of these Draft opcodes are intended for private custom
  92 secret proprietary usage. They are all intended for entirely
  93 public, upstream, high-profile mass-volume day-to-day usage at the
  94 same level as add, popcnt and fld**
  95
  96 * SVP64 requires 25% of EXT01 (bits 6 and 9 set to 1)
  97 * bitmanip requires two major opcodes (due to 16+ bit immediates)
  98   those are currently EXT022 and EXT05.
  99 * brownfield encoding in one of those two major opcodes still
 100   requires multiple VA-Form operations (in greater numbers
 101   than EXT04 has spare)
 102 * space in EXT019 next to addpcis and crops is recommended
 103 * many X-Form opcodes currently in EXT022 have no preference
 104   for a location at all, and may be moved to EXT059, EXT019,
 105   EXT031 or other much more suitable location.
 106
 107 Note that there is no Sandbox allocation in the published ISA Spec for
 108 v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
 109 Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
 110 would become a whopping 96-bit long instruction. Avoiding this
 111 situation is a high priority which in turn by necessity puts pressure
 112 on the 32-bit Major Opcode space.
 113
 114 Note also that EXT022, the Official Architectural Sandbox area
 115 is under severe design pressure as it is insufficient to hold
 116 the full extent of the instruction additions required to create
 117 a Hybrid 3D CPU-VPU-GPU.
 118
 119 **Whilst SVP64 is only 4 instructions
 120 the heavy focus on VSX for the past 12 years has left the SFFS Level
 121 anaemic and out-of-date compared to ARM and x86. Approximately
 122 100 additional Scalar Instructions are up for proposal**
 123
 124 # Sub-pages
 125
 126 Pages being developed and examples
 127
 128 * [[sv/overview]] explaining the basics.
 129 * [[sv/compliancy_levels]] for minimum subsets through to Advanced
 130   Supercomputing.
 131 * [[sv/implementation]] implementation planning and coordination
 132 * [[sv/svp64]] contains the packet-format *only*, the [[sv/svp64/appendix]]
 133   contains explanations and further details
 134 * [[sv/svp64_quirks]] things in SVP64  that slightly break the rules
 135 * [[opcode_regs_deduped]] autogenerated table of SVP64 decoder augmentation
 136 * [[sv/vector_comparative_analysis] - a list of Packed SIMD, GPU,
 137   and other Scalable Vector ISAs
 138 * [[sv/sprs]] SPRs
 139 * SVP64 "Modes":
 140   - For condition register operations see [[sv/cr_ops]] - SVP64 Condition
 141     Register ops: Guidelines
 142     on Vectorisation of any v3.0B base operations which return
 143     or modify a Condition Register bit or field.
 144   - For LD/ST Modes, see [[sv/ldst]].
 145   - For Branch modes, see [[sv/branches]] - SVP64 Conditional Branch
 146     behaviour: All/Some Vector CRs
 147   - For arithmetic and logical, see [[sv/normal]]
 148   - [[sv/mv.vec]] pack/unpack move to and from vec2/3/4,
 149     actually an RM.EXTRA Mode and a [[sv/remap] mode
 150
 151 Core SVP64 instructions:
 152
 153 * [[sv/setvl]] the Cray-style "Vector Length" instruction
 154 * [[sv/remap]] "Remapping" for Matrix Multiply and RGB "Structure Packing"
 155 * [[sv/svstep]] Key stepping instruction for Vertical-First Mode
 156
 157 *Please note: there are only five instructions in the whole of SV.
 158 Beyond this point are additional **Scalar** instructions related to
 159 specific workloads that have nothing to do with the SV Specification**
 160
 161 **Additional Instructions for specific purposes (not SVP64)**
 162
 163 All of these instructions below have nothing to do with SV.
 164 They are all entirely designed as Scalar instructions that, as
 165 Scalar instructions, stand on their own merit. Considerable
 166 lengths have been made to provide justifications for each of these
 167 *Scalar* instructions.
 168
 169 Vector-related:
 170
 171 * [[sv/vector_swizzle]]
 172 * [[sv/mv.swizzle]] vec2/3/4 Swizzles (RGBA, XYZW) for 3D and CUDA.
 173   designed as a Scalar instruction.
 174 * [[sv/vector_ops]] scalar operations needed for supporting vectors
 175
 176 Scalar Instructions:
 177
 178 * [[sv/cr_int_predication]] instructions needed for effective predication
 179 * [[sv/bitmanip]]
 180 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
 181 * [[sv/fclass]] detect class of FP numbers
 182 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
 183 * [[sv/vector_ops]] Vector ops needed to make a "complete" Vector ISA
 184 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
 185 * Twin targetted instructions (two registers out, one implicit)
 186   Explanation of the rules for twin register targets
 187   (implicit RS, FRS) explained in SVP64 [[sv/svp64/appendix]]
 188   - [[isa/svfixedarith]]
 189   - [[isa/svfparith]]
 190   - [[sv/biginteger]] Operations that help with big arithmetic
 191 * TODO: OpenPOWER adaptation [[openpower/transcendentals]]
 192
 193 Examples experiments future ideas discussion:
 194
 195 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
 196 * [[sv/masked_vector_chaining]]
 197 * [[sv/discussion]]
 198 * [[sv/example_dep_matrices]]
 199 * [[sv/major_opcode_allocation]]
 200 * [[sv/byteswap]]
 201 * [[sv/16_bit_compressed]] experimental
 202 * [[sv/toc_data_pointer]] experimental
 203 * [[sv/predication]] discussion on predication concepts
 204 * [[sv/register_type_tags]]
 205 * [[sv/mv.x]] deprecated in favour of Indexed REMAP
 206
 207 Additional links:
 208
 209 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
 210 * [[simple_v_extension]] old (deprecated) version
 211 * [[openpower/sv/llvm]]
 212 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
 213