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   (or any 5-6 bit Minor XO areas)
 104 * many X-Form opcodes currently in EXT022 have no preference
 105   for a location at all, and may be moved to EXT059, EXT019,
 106   EXT031 or other much more suitable location.
 107
 108 Note that there is no Sandbox allocation in the published ISA Spec for
 109 v3.1 EXT01 usage, and because SVP64 is already 64-bit Prefixed,
 110 Prefixed-Prefixed-instructions (SVP64 Prefixed v3.1 Prefixed)
 111 would become a whopping 96-bit long instruction. Avoiding this
 112 situation is a high priority which in turn by necessity puts pressure
 113 on the 32-bit Major Opcode space.
 114
 115 Note also that EXT022, the Official Architectural Sandbox area
 116 is under severe design pressure as it is insufficient to hold
 117 the full extent of the instruction additions required to create
 118 a Hybrid 3D CPU-VPU-GPU.
 119
 120 **Whilst SVP64 is only 4 instructions
 121 the heavy focus on VSX for the past 12 years has left the SFFS Level
 122 anaemic and out-of-date compared to ARM and x86. Approximately
 123 100 additional Scalar Instructions are up for proposal**
 124
 125 # Sub-pages
 126
 127 Pages being developed and examples
 128
 129 * [[sv/overview]] explaining the basics.
 130 * [[sv/compliancy_levels]] for minimum subsets through to Advanced
 131   Supercomputing.
 132 * [[sv/implementation]] implementation planning and coordination
 133 * [[sv/svp64]] contains the packet-format *only*, the [[sv/svp64/appendix]]
 134   contains explanations and further details
 135 * [[sv/svp64_quirks]] things in SVP64  that slightly break the rules
 136 * [[opcode_regs_deduped]] autogenerated table of SVP64 decoder augmentation
 137 * [[sv/vector_comparative_analysis] - a list of Packed SIMD, GPU,
 138   and other Scalable Vector ISAs
 139 * [[sv/sprs]] SPRs
 140 * SVP64 "Modes":
 141   - For condition register operations see [[sv/cr_ops]] - SVP64 Condition
 142     Register ops: Guidelines
 143     on Vectorisation of any v3.0B base operations which return
 144     or modify a Condition Register bit or field.
 145   - For LD/ST Modes, see [[sv/ldst]].
 146   - For Branch modes, see [[sv/branches]] - SVP64 Conditional Branch
 147     behaviour: All/Some Vector CRs
 148   - For arithmetic and logical, see [[sv/normal]]
 149   - [[sv/mv.vec]] pack/unpack move to and from vec2/3/4,
 150     actually an RM.EXTRA Mode and a [[sv/remap]] mode
 151
 152 Core SVP64 instructions:
 153
 154 * [[sv/setvl]] the Cray-style "Vector Length" instruction
 155 * [[sv/remap]] "Remapping" for Matrix Multiply and RGB "Structure Packing"
 156 * [[sv/svstep]] Key stepping instruction for Vertical-First Mode
 157
 158 *Please note: there are only five instructions in the whole of SV.
 159 Beyond this point are additional **Scalar** instructions related to
 160 specific workloads that have nothing to do with the SV Specification**
 161
 162 **Additional Instructions for specific purposes (not SVP64)**
 163
 164 All of these instructions below have nothing to do with SV.
 165 They are all entirely designed as Scalar instructions that, as
 166 Scalar instructions, stand on their own merit. Considerable
 167 lengths have been made to provide justifications for each of these
 168 *Scalar* instructions.
 169
 170 Vector-related:
 171
 172 * [[sv/vector_swizzle]]
 173 * [[sv/mv.swizzle]] vec2/3/4 Swizzles (RGBA, XYZW) for 3D and CUDA.
 174   designed as a Scalar instruction.
 175 * [[sv/vector_ops]] scalar operations needed for supporting vectors
 176
 177 Scalar Instructions:
 178
 179 * [[sv/cr_int_predication]] instructions needed for effective predication
 180 * [[sv/bitmanip]]
 181 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
 182 * [[sv/fclass]] detect class of FP numbers
 183 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
 184 * [[sv/vector_ops]] Vector ops needed to make a "complete" Vector ISA
 185 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
 186 * Twin targetted instructions (two registers out, one implicit)
 187   Explanation of the rules for twin register targets
 188   (implicit RS, FRS) explained in SVP64 [[sv/svp64/appendix]]
 189   - [[isa/svfixedarith]]
 190   - [[isa/svfparith]]
 191   - [[sv/biginteger]] Operations that help with big arithmetic
 192 * TODO: OpenPOWER adaptation [[openpower/transcendentals]]
 193
 194 Examples experiments future ideas discussion:
 195
 196 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
 197 * [[sv/masked_vector_chaining]]
 198 * [[sv/discussion]]
 199 * [[sv/example_dep_matrices]]
 200 * [[sv/major_opcode_allocation]]
 201 * [[sv/byteswap]]
 202 * [[sv/16_bit_compressed]] experimental
 203 * [[sv/toc_data_pointer]] experimental
 204 * [[sv/predication]] discussion on predication concepts
 205 * [[sv/register_type_tags]]
 206 * [[sv/mv.x]] deprecated in favour of Indexed REMAP
 207
 208 Additional links:
 209
 210 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
 211 * [[simple_v_extension]] old (deprecated) version
 212 * [[openpower/sv/llvm]]
 213 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
 214