hack to put comparison table on one page
[libreriscv.git] / openpower / sv / overview.mdwn
index a599b2eab29066acae6adb8e90ba17705d1bfad4..f4dab4b36e51442cf9be0fbc0bd698fcdce8e98f 100644 (file)
@@ -1,16 +1,18 @@
 # SV Overview
 
-**SV is in DRAFT STATUS**. SV has not yet been submitted to the OpenPOWER Foundation ISA WG for review.
+**SV is in DRAFT STATUS**. SV has not yet been submitted to the OpenPOWER
+Foundation ISA WG for review.
 
 This document provides an overview and introduction as to why SV (a
-[[!wikipedia Cray]]-style Vector augmentation to [[!wikipedia OpenPOWER]]) exists, and how it works.
+[[!wikipedia Cray]]-style Vector augmentation to
+[[!wikipedia OpenPOWER]]) exists, and how it works.
 
 **Sponsored by NLnet under the Privacy and Enhanced Trust Programme**
 
 Links:
 
 * This page: [http://libre-soc.org/openpower/sv/overview](http://libre-soc.org/openpower/sv/overview)
-* [FOSDEM2021 SimpleV for OpenPOWER](https://fosdem.org/2021/schedule/event/the_libresoc_project_simple_v_vectorisation/)
+* [FOSDEM2021 SimpleV for Power ISA](https://fosdem.org/2021/schedule/event/the_libresoc_project_simple_v_vectorisation/)
 * FOSDEM2021 presentation <https://www.youtube.com/watch?v=FS6tbfyb2VA>
 * [[discussion]] and
   [bugreport](https://bugs.libre-soc.org/show_bug.cgi?id=556)
@@ -75,6 +77,8 @@ a register file size
 increase using "tagging" (similar to how x86 originally extended
 registers from 32 to 64 bit).
 
+![Single-Issue concept](/openpower/svp64-primer/img/power_pipelines.svg)
+
 ## SV
 
 The fundamentals are (just like x86 "REP"):
@@ -91,7 +95,7 @@ The fundamentals are (just like x86 "REP"):
 * Once the loop is completed *only then* is the Program Counter
   allowed to move to the next instruction.
 
-![image](/svp64-primer/img/power_pipelines.svg)
+![Multi-Issue with Predicated SIMD back-end ALUs](/openpower/svp64-primer/img/sv_multi_issue.svg)
 
 Hardware (and simulator) implementors are free and clear to implement this
 as literally a for-loop, sitting in between instruction decode and issue.
@@ -99,7 +103,7 @@ Higher performance systems may deploy SIMD backends, multi-issue and
 out-of-order execution, although it is strongly recommended to add
 predication capability directly into SIMD backend units.
 
-In OpenPOWER ISA v3.0B pseudo-code form, an ADD operation, assuming both
+In Power ISA v3.0B pseudo-code form, an ADD operation, assuming both
 source and destination have been "tagged" as Vectors, is simply:
 
     for i = 0 to VL-1:
@@ -115,14 +119,14 @@ additional instructions have been added, almost all of them SIMD.
 
 RISC-V RVV as of version 0.9 is over 188 instructions (more than the
 rest of RV64G combined: 80 for RV64G and 27 for C). Over 95% of that
-functionality is added to OpenPOWER v3 0B, by SimpleV augmentation,
+functionality is added to Power v3.0B, by SimpleV augmentation,
 with around 5 to 8 instructions.
 
-Even in OpenPOWER v3.0B, the Scalar Integer ISA is around 150
+Even in Power ISA v3.0B, the Scalar Integer ISA is around 150
 instructions, with IEEE754 FP adding approximately 80 more. VSX, being
 based on SIMD design principles, adds somewhere in the region of 600 more.
 SimpleV again provides over 95% of VSX functionality, simply by augmenting
-the *Scalar* OpenPOWER ISA, and in the process providing features such
+the *Scalar* Power ISA, and in the process providing features such
 as predication, which VSX is entirely missing.
 
 AVX512, SVE2, VSX, RVV, all of these systems have to provide different
@@ -130,7 +134,7 @@ types of register files: Scalar and Vector is the minimum. AVX512
 even provides a mini mask regfile, followed by explicit instructions
 that handle operations on each of them *and map between all of them*.
 SV simply not only uses the existing scalar regfiles (including CRs),
-but because operations exist within OpenPOWER to cover interactions
+but because operations exist within Power ISA to cover interactions
 between the scalar regfiles (`mfcr`, `fcvt`) there is very little that
 needs to be added.
 
@@ -141,9 +145,7 @@ by SimpleV:
   (VSX Rijndael and SHA primitives; VSX shuffle and bitpermute operations)
 * register files above 128 entries
 * Vector lengths over 64
-* Unit-strided LD/ST and other comprehensive memory operations
-  (struct-based LD/ST from RVV for example)
-* 32-bit instruction lengths. [[svp64]] had to be added as 64 bit.
+* 32-bit instruction lengths. [[sv/svp64]] had to be added as 64 bit.
 
 These limitations, which stem inherently from the adaptation process of
 starting from a Scalar ISA, are not insurmountable. Over time, they may
@@ -163,7 +165,7 @@ The rest of this document builds on the above simple loop to add:
 * A completely new concept: "Twin Predication"
 * vec2/3/4 "Subvectors" and Swizzling (standard fare for 3D)
 
-All of this is *without modifying the OpenPOWER v3.0B ISA*, except to add
+All of this is *without modifying the Power v3.0B ISA*, except to add
 "wrapping context", similar to how v3.1B 64 Prefixes work.
 
 # Adding Scalar / Vector
@@ -247,7 +249,7 @@ Condition Registers have a slightly different scheme, along the same
 principle, which takes into account the fact that each CR may be bit-level
 addressed by Condition Register operations.
 
-Readers familiar with OpenPOWER will know of Rc=1 operations that create
+Readers familiar with the Power ISA will know of Rc=1 operations that create
 an associated post-result "test", placing this test into an implicit
 Condition Register.  The original researchers who created the POWER ISA
 chose CR0 for Integer, and CR1 for Floating Point.  These *also become
@@ -291,7 +293,7 @@ one single entry from a Vector.
 If all three registers are marked as Vector then the "traditional"
 predicated Vector behaviour is provided.  Yet, just as before, all other
 options are still provided, right the way back to the pure-scalar case,
-as if this were a straight OpenPOWER v3.0B non-augmented instruction.
+as if this were a straight Power ISA v3.0B non-augmented instruction.
 
 Single Predication therefore provides several modes traditionally seen
 in Vector ISAs:
@@ -350,7 +352,7 @@ example) 64 bit operations (only).  The override widths are 8, 16 and
 32 for integer, and FP16 and FP32 for IEEE754 (with BF16 to be added in
 the future).
 
-This presents a particularly intriguing conundrum given that the OpenPOWER
+This presents a particularly intriguing conundrum given that the Power
 Scalar ISA was never designed with for example 8 bit operations in mind,
 let alone Vectors of 8 bit.
 
@@ -372,7 +374,7 @@ structure, where all types uint16_t etc. are in little-endian order:
         uint8_t  b[0]; // array of type uint8_t
         uint16_t s[0]; // array of LE ordered uint16_t
         uint32_t i[0];
-        uint64_t l[0]; // default OpenPOWER ISA uses this
+        uint64_t l[0]; // default Power ISA uses this
     } reg_t;
 
     reg_t int_regfile[128]; // SV extends to 128 regs
@@ -381,6 +383,8 @@ This means that Vector elements start from locations specified by 64 bit
 "register" but that from that location onwards the elements *overlap
 subsequent registers*.
 
+![image](/openpower/svp64-primer/img/svp64_regs.svg){ width=40% }
+
 Here is another way to view the same concept, bearing in mind that it
 is assumed a LE memory order:
 
@@ -521,7 +525,7 @@ Consequently it becomes critically important to decide a byte-order.
 That decision was - arbitrarily - LE mode.  Actually it wasn't arbitrary
 at all: it was such hell to implement BE supported interpretations of CRs
 and LD/ST in LibreSOC, based on a terse spec that provides insufficient
-clarity and assumes significant working knowledge of OpenPOWER, with
+clarity and assumes significant working knowledge of the Power ISA, with
 arbitrary insertions of 7-index here and 3-bitindex there, the decision
 to pick LE was extremely easy.
 
@@ -727,15 +731,15 @@ those:
     swizzle = get_swizzle_immed() # 12 bits
     for (s = 0; s < SUBVL; s++)
         remap = (swizzle >> 3*s) & 0b111
-        if remap < 4:
-           sm = id*SUBVL + remap
+        if remap == 0b000: continue            # skip
+        if remap == 0b001: break               # end marker
+        if remap == 0b010: ireg[rd+s] <= 0.0   # constant 0
+        elif remap == 0b011: ireg[rd+s] <= 1.0 # constant 1
+        else:                                  # XYZW
+           sm = id*SUBVL + (remap-4)
            ireg[rd+s] <= ireg[RA+sm]
-        elif remap == 4:
-              ireg[rd+s] <= 0.0
-        elif remap == 5:
-              ireg[rd+s] <= 1.0
 
-Note that a value of 6 (and 7) will leave the target subvector element
+Note that a value of 0b000 will leave the target subvector element
 untouched. This is equivalent to a predicate mask which is built-in,
 in immediate form, into the [[sv/mv.swizzle]] operation.  mv.swizzle is
 rare in that it is one of the few instructions needed to be added that
@@ -792,7 +796,7 @@ VGATHER/VSCATTER.
 
 # CR predicate result analysis
 
-OpenPOWER has Condition Registers.  These store an analysis of the result
+Power ISA has Condition Registers.  These store an analysis of the result
 of an operation to test it for being greater, less than or equal to zero.
 What if a test could be done, similar to branch BO testing, which hooked
 into the predication system?
@@ -935,6 +939,8 @@ loop:
   beq loop
 ```
 
+![image](/openpower/sv/sv_horizontal_vs_vertical.svg)
+
 Three examples are illustrated of different types of Scalar-Vector
 operations. Note that in its simplest form  **only one** element is
 executed per instruction **not** multiple elements per instruction.
@@ -971,16 +977,16 @@ The other key question is of course: what's the actual instruction format,
 and what's in it? Bearing in mind that this requires OPF review, the
 current draft is at the [[sv/svp64]] page, and includes space for all the
 different modes, the predicates, element width overrides, SUBVL and the
-register extensions, in 24 bits.  This just about fits into an OpenPOWER
+register extensions, in 24 bits.  This just about fits into a Power
 v3.1B 64 bit Prefix by borrowing some of the Reserved Encoding space.
-The v3.1B suffix - containing as it does a 32 bit OpenPOWER instruction -
+The v3.1B suffix - containing as it does a 32 bi Power instruction -
 aligns perfectly with SV.
 
 Further reading is at the main [[SV|sv]] page.
 
 # Conclusion
 
-Starting from a scalar ISA - OpenPOWER v3.0B - it was shown above that,
+Starting from a scalar ISA - Power v3.0B - it was shown above that,
 with conceptual sub-loops, a Scalar ISA can be turned into a Vector one,
 by embedding Scalar instructions - unmodified - into a Vector "context"
 using "Prefixing".  With careful thought, this technique reaches 90%