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 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 ones.
  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 XER.SO for example)
  35 * Designed for Supercomputing: avoids creating significant sequential
  36   dependency hazards, allowing high performance superscalar
  37   microarchitectures to be deployed.
  38
  39 Advantages of these design principles:
  40
  41 * It is therefore easy to create a first (and sometimes only)
  42   implementation as literally a for-loop in hardware, simulators, and
  43   compilers.
  44 * Hardware Architects may understand and implement SV as being an
  45   extra pipeline stage, inserted between decode and issue, that is
  46   a simple for-loop issuing element-level sub-instructions.
  47 * More complex HDL can be done by repeating existing scalar ALUs and
  48   pipelines as blocks and leveraging existing Multi-Issue Infrastructure
  49 * As (mostly) a high-level "context" that does not (significantly) deviate
  50   from scalar Power ISA and, in its purest form being "a for loop around
  51   scalar instructions", it is minimally-disruptive and consequently stands
  52   a reasonable chance of broad community adoption and acceptance
  53 * Completely wipes not just SIMD opcode proliferation off the
  54   map (SIMD is O(N^6) opcode proliferation)
  55   but off of Vectorisation ISAs as well.  No more separate Vector
  56   instructions.
  57
  58 Comparative instruction count:
  59
  60 * ARM NEON SIMD: around 2,000 instructions, prerequisite: ARM Scalar.
  61 * ARM SVE: around 4,000 instructions, prerequisite: NEON.
  62 * ARM SVE2: around 1,000 instructions, prerequisite: SVE
  63 * Intel AVX-512: around 4,000 instructions, prerequisite AVX2 etc.
  64 * RISV-V RVV: 192 instructions, prerequisite 96 Scalar RV64GC instructions
  65 * SVP64: **four** instructions, 24-bit prefixing of
  66   prerequisite SFS (150) or
  67   SFFS (214) Compliancy Subsets
  68
  69 SV comprises several [[sv/compliancy_levels]] suited to Embedded, Energy
  70 efficient High-Performance Compute, Distributed Computing and Advanced
  71 Computational Supercomputing.  The Compliancy Levels are arranged such
  72 that even at the bare minimum Level, full Soft-Emulation of all
  73 optional and future features is possible.
  74
  75 # Major opcodes summary
  76
  77 Please be advised that even though below is entirely DRAFT status, there
  78 is considerable concern that because there is not yet any two-way
  79 day-to-day communication established with the OPF ISA WG, we have
  80 no idea if any of these are conflicting with future plans by any OPF
  81 Members.  **The External ISA WG RFC Process is yet to be ratified
  82 and Libre-SOC may not join the OPF as an entity because it does
  83 not exist except in name. Even if it existed it would be a conflict
  84 of interest to join the OPF, due to our funding remit from NLnet**.
  85 We therefore proceed on the basis of making public the intention to
  86 submit RFCs once the External ISA WG RFC Process is in place and,
  87 in a wholly unsatisfactory manner have to *hope and trust* that
  88 OPF ISA WG Members are reading this and take it into consideration.
  89
  90 **None of these Draft opcodes are intended for private custom
  91 secret proprietary usage. They are all intended for entirely
  92 public, upstream, high-profile mass-volume day-to-day usage at the
  93 same level as add, popcnt and fld**
  94
  95 * SVP64 requires 25% of EXT01 (bits 6 and 9 set to 1)
  96 * bitmanip requires two major opcodes (due to 16+ bit immediates)
  97   those are currently EXT022 and EXT05.
  98 * brownfield encoding in one of those two major opcodes still
  99   requires multiple VA-Form operations (in greater numbers
 100   than EXT04 has spare)
 101 * space in EXT019 next to addpcis and crops is recommended
 102 * many X-Form opcodes currently in EXT022 have no preference
 103   for a location at all, and may be moved to EXT059, EXT019,
 104   EXT031 or other much more suitable location.
 105
 106 Note that there is no Sandbox allocation in the published ISA Spec for
 107 v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
 108 Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
 109 would become a whopping 96-bit long instruction. Avoiding this
 110 situation is a high priority which in turn by necessity puts pressure
 111 on the 32-bit Major Opcode space.
 112
 113 Note also that EXT022, the Official Architectural Sandbox area
 114 is under severe design pressure as it is insufficient to hold
 115 the full extent of the instruction additions required to create
 116 a Hybrid 3D CPU-VPU-GPU.
 117
 118 **Whilst SVP64 is only 4 instructions
 119 the heavy focus on VSX for the past 12 years has left the SFFS Level
 120 anaemic and out-of-date compared to ARM and x86. Approximately
 121 100 additional Scalar Instructions are up for proposal**
 122
 123 # Sub-pages
 124
 125 Pages being developed and examples
 126
 127 * [[sv/overview]] explaining the basics.
 128 * [[sv/compliancy_levels]] for minimum subsets through to Advanced
 129   Supercomputing.
 130 * [[sv/implementation]] implementation planning and coordination
 131 * [[sv/svp64]] contains the packet-format *only*, the [[sv/svp64/appendix]]
 132   contains explanations and further details
 133 * [[sv/svp64_quirks]] things in SVP64  that slightly break the rules
 134 * [[opcode_regs_deduped]] autogenerated table of SVP64 instructions
 135 * [[sv/vector_comparative_analysis] - a list of Packed SIMD, GPU,
 136   and other Scalable Vector ISAs
 137 * [[sv/sprs]] SPRs
 138 * SVP64 "Modes":
 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
 148 Core SVP64 instructions:
 149
 150 * [[sv/setvl]] the Cray-style "Vector Length" instruction
 151 * [[sv/remap]] "Remapping" for Matrix Multiply and RGB "Structure Packing"
 152 * [[sv/svstep]] Key stepping instruction for Vertical-First Mode
 153
 154 Vector-related:
 155
 156 * [[sv/vector_swizzle]]
 157 * [[sv/mv.vec]] pack/unpack move to and from vec2/3/4
 158 * [[sv/mv.swizzle]]
 159 * [[sv/vector_ops]] scalar operations needed for supporting vectors
 160
 161 Scalar Instructions:
 162
 163 * [[sv/cr_int_predication]] instructions needed for effective predication
 164 * [[sv/bitmanip]]
 165 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
 166 * [[sv/fclass]] detect class of FP numbers
 167 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
 168 * [[sv/vector_ops]] Vector ops needed to make a "complete" Vector ISA
 169 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
 170 * Twin targetted instructions (two registers out, one implicit)
 171   Explanation of the rules for twin register targets
 172   (implicit RS, FRS) explained in SVP64 [[sv/svp64/appendix]]
 173   - [[isa/svfixedarith]]
 174   - [[isa/svfparith]]
 175   - [[sv/biginteger]] Operations that help with big arithmetic
 176 * TODO: OpenPOWER adaptation [[openpower/transcendentals]]
 177
 178 Examples experiments future ideas discussion:
 179
 180 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
 181 * [[sv/masked_vector_chaining]]
 182 * [[sv/discussion]]
 183 * [[sv/example_dep_matrices]]
 184 * [[sv/major_opcode_allocation]]
 185 * [[sv/byteswap]]
 186 * [[sv/16_bit_compressed]] experimental
 187 * [[sv/toc_data_pointer]] experimental
 188 * [[sv/predication]] discussion on predication concepts
 189 * [[sv/register_type_tags]]
 190 * [[sv/mv.x]] deprecated in favour of Indexed REMAP
 191
 192 Additional links:
 193
 194 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
 195 * [[simple_v_extension]] old (deprecated) version
 196 * [[openpower/sv/llvm]]
 197 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
 198