# RFC ls008 SVP64 Management instructions
-[[!tag opf_rfc]]
-
**URLs**:
* <https://libre-soc.org/openpower/sv/>
* <https://libre-soc.org/openpower/sv/rfc/ls008/>
* <https://bugs.libre-soc.org/show_bug.cgi?id=1040>
-* <https://git.openpower.foundation/isa/PowerISA/issues/87>
+* <https://git.openpower.foundation/isa/PowerISA/issues/123>
**Severity**: Major
**Summary**
```
- Instructions added
setvl - Cray-style "Set Vector Length" instruction
svstep - Vertical-First Mode explicit Step and Status
- svremap - Re-Mapping of Register Element Offsets
- svindex - General-purpose setting of SHAPEs to be re-mapped
- svshape - Hardware-level setting of SHAPEs for element re-mapping
- svshape2 - Hardware-level setting of SHAPEs for element re-mapping (v2)
```
**Submitter**: Luke Leighton (Libre-SOC)
**Impact on processor**:
```
- Addition of six new "Zero-Overhead-Loop-Control" DSP-style Vector-style
+ Addition of two new "Zero-Overhead-Loop-Control" DSP-style Vector-style
Management Instructions which can be implemented extremely efficiently
and effectively by inserting an additional phase between Decode and Issue.
More complex designs are NOT adversely impacted and in fact greatly benefit
- whilst still retaining an obvious linear sequential execution programming model.
```
**Impact on software**:
**Keywords**:
```
- Cray Supercomputing, Vectorisation, Zero-Overhead-Loop-Control,
- Scalable Vectors, Multi-Issue Out-of-Order, Sequential Programming Model
+ Cray Supercomputing, Vectorisation, Zero-Overhead-Loop-Control (ZOLC),
+ Scalable Vectors, Multi-Issue Out-of-Order, Sequential Programming Model,
+ Digital Signal Processing (DSP)
```
**Motivation**
-TODO
+Power ISA is synonymous with Supercomputing and the early Supercomputers
+(ETA-10, ILLIAC-IV, CDC200, Cray) had Vectorisation. It is therefore anomalous
+that Power ISA does not have Scalable Vectors. This presents the opportunity to
+modernise Power ISA keeping it at the top of Supercomputing.
**Notes and Observations**:
-1. TODO
+1. SVP64 is very much designed for ultra-light-weight Embedded use-cases all the
+ way up to moving the bar of Supercomputing orders of magnitude above its present
+ perception, whilst retaining at all times Sequential Programming Execution.
+2. This proposal is the **base** for further Extensions. These include
+ extending SVP64 onto the Scalar VSX instructions (with a **LONG TERM** view in 10+ years
+ to deprecating the PackedSIMD aspects of VSX), to be discussed at a later
+ time, the potential for extending VSX registers to 128 or beyond, and Arithmetic
+ operations to a runtime-selectable choice of 128-bit, 256-bit, 512-bit or 1024-bit.
+3. Massive reductions in instruction count of between 2x and 20x have been demonstrated
+ with SVP64, which is far beyond anything ever achieved by any *general-purpose*
+ ISA Extension added to any ISA in the history of Computing.
**Changes**
Add the following entries to:
+* Section 1.3.2 Notation
* the Appendices of Book I
* Instructions of Book I as a new Section
* SVL-Form of Book I Section 1.6.1.6 and 1.6.2
\newpage{}
-# svstep: Vertical-First Stepping and status reporting
-
-SVL-Form
-
-* svstep RT,SVi,vf (Rc=0)
-* svstep. RT,SVi,vf (Rc=1)
+# Notation, Section 1.3.2
-| 0-5|6-10|11.15|16..22| 23-25 | 26-30 |31| Form |
-|----|----|-----|------|----------|-------|--|--------- |
-|PO | RT | / | SVi | / / vf | XO |Rc| SVL-Form |
-
-Pseudo-code:
-
-```
- if SVi[3:4] = 0b11 then
- # store subvl, pack and unpack in SVSTATE
- SVSTATE[53] <- SVi[5]
- SVSTATE[54] <- SVi[6]
- RT <- [0]*62 || SVSTATE[53:54]
- else
- step <- SVSTATE_NEXT(SVi, vf)
- RT <- [0]*57 || step
+When destination register operands (`RT, RS`) are prefixed by a single
+underscore (`_RT, _RS`) the variable also contains the contents of the
+instruction field.
+This avoids confusion in pseudocode when a destination register is
+assigned (`RT <- x`) but earlier it was the operand bits that were
+checked (`if RT = 0`)
-```
-
-Special Registers Altered:
-
- CR0 (if Rc=1)
-
-
--------------
+----------------
\newpage{}
-
-# setvl
-
-SVL-Form
-
-* setvl RT,RA,SVi,vf,vs,ms (Rc=0)
-* setvl. RT,RA,SVi,vf,vs,ms (Rc=1)
-
-Pseudo-code:
-
- overflow <- 0b0
- VLimm <- SVi + 1
- # set or get MVL
- if ms = 1 then MVL <- VLimm[0:6]
- else MVL <- SVSTATE[0:6]
- # set or get VL
- if vs = 0 then VL <- SVSTATE[7:13]
- else if _RA != 0 then
- if (RA) >u 0b1111111 then
- VL <- 0b1111111
- overflow <- 0b1
- else VL <- (RA)[57:63]
- else if _RT = 0 then VL <- VLimm[0:6]
- else if CTR >u 0b1111111 then
- VL <- 0b1111111
- overflow <- 0b1
- else VL <- CTR[57:63]
- # limit VL to within MVL
- if VL >u MVL then
- overflow <- 0b1
- VL <- MVL
- SVSTATE[0:6] <- MVL
- SVSTATE[7:13] <- VL
- if _RT != 0 then
- GPR(_RT) <- [0]*57 || VL
- if ((¬vs) & ¬(ms)) = 0 then
- # set requested Vertical-First mode, clear persist
- SVSTATE[63] <- vf
- SVSTATE[62] <- 0b0
-
-Special Registers Altered:
-
- CR0 (if Rc=1)
-
--------------
-
-\newpage{}
+[[!inline pages="openpower/sv/svstep" raw=yes ]]
+[[!inline pages="openpower/sv/setvl" raw=yes ]]
# SVSTATE SPR
| 21:27 | dststep | for dststep = 0..VL-1 |
| 28:29 | dsubstep | for substep = 0..SUBVL-1 |
| 30:31 | ssubstep | for substep = 0..SUBVL-1 |
-| 32:33 | mi0 | REMAP RA SVSHAPE0-3 |
-| 34:35 | mi1 | REMAP RB SVSHAPE0-3 |
-| 36:37 | mi2 | REMAP RC SVSHAPE0-3 |
-| 38:39 | mo0 | REMAP RT SVSHAPE0-3 |
-| 40:41 | mo1 | REMAP EA SVSHAPE0-3 |
+| 32:33 | mi0 | REMAP RA/FRA/BFA SVSHAPE0-3 |
+| 34:35 | mi1 | REMAP RB/FRB/BFB SVSHAPE0-3 |
+| 36:37 | mi2 | REMAP RC/FRT SVSHAPE0-3 |
+| 38:39 | mo0 | REMAP RT/FRT/BF SVSHAPE0-3 |
+| 40:41 | mo1 | REMAP EA/RS/FRS SVSHAPE0-3 |
| 42:46 | SVme | REMAP enable (RA-RT) |
| 47:52 | rsvd | reserved |
| 53 | pack | PACK (srcstrp reorder) |
* Pack - if set then srcstep/substep VL/SUBVL loop-ordering is inverted.
* UnPack - if set then dststep/substep VL/SUBVL loop-ordering is inverted.
* hphint - Horizontal Parallelism Hint. Indicates that
- no Hazards exist between this number of sequentially-accessed
- elements (including after REMAP). In Vertical First Mode
- hardware **MUST** perform this many elements in parallel
- per instruction. Set to zero to indicate "no hint".
+ no Hazards exist between groups of elements in sequential multiples of this number
+ (before REMAP). By definition: elements for which `FLOOR(srcstep/hphint)` is
+ equal *before REMAP* are in the same parallelism "group". In Vertical First Mode
+ hardware **MUST ONLY** process elements in the same group, and must stop
+ Horizontal Issue at the last element of a given group. Set to zero to indicate "no hint".
* SVme - REMAP enable bits, indicating which register is to be
- REMAPed. RA, RB, RC, RT or EA.
-* mi0-mi4 - when the corresponding SVme bit is enabled, mi0-mi4
+ REMAPed: RA, RB, RC, RT and EA are the canonical (typical) register names
+ associated with each bit, with RA being the LSB and EA being the MSB.
+ See table below for ordering. When `SVme` is zero (0b00000) REMAP
+ is **fully disabled and inactive** regardless of the contents of
+ `SVSTATE`, `mi0-mi2/mo0-mo1`, or the four `SVSHAPEn` SPRs
+* mi0-mi2/mo0-mo1 - when the corresponding SVme bit is enabled, these
indicate the SVSHAPE (0-3) that the corresponding register (RA etc)
- should use.
+ should use, as long as the register's corresponding SVme bit is set
+
+Programmer's Note: the fact that REMAP is entirely dormant when `SVme` is zero
+allows establishment of REMAP context well in advance, followed by utilising `svremap`
+at a precise (or the very last) moment. Some implementations may exploit this
+to cache (or take some time to prepare caches) in the background whilst other
+(unrelated) instructions are being executed. This is particularly important to
+bear in mind when using `svindex` which will require hardware to perform (and
+cache) additional GPR reads.
Programmer's Note: when REMAP is activated it becomes necessary on any
context-switch (Interrupt or Function call) to detect (or know in advance)
**Max Vector Length (maxvl)** <a name="mvl" />
MAXVECTORLENGTH is the same concept as MVL in RISC-V RVV, except that it
-is variable length and may be dynamically set. MVL is limited to 7 bits
+is variable length and may be dynamically set (normally from an immediate
+field only). MVL is limited to 7 bits
(in the first version of SVP64) and consequently the maximum number of
elements is limited to between 0 and 127.
It may **NOT** be set dynamically from a register. Compiler writers and assembly
programmers are expected to perform static register file analysis, subdivision,
and allocation and only utilise `setvl`. Direct writing to SVSTATE in order to
-"bypass" this Note could, in less-advanced implementations, potentially cause stalling.
+"bypass" this Note could, in less-advanced implementations, potentially cause stalling,
+particularly if SVP64 instructions are issued directly after the `mtspr` to SVSTATE.
**Vector Length (vl)** <a name="vl" />
+The actual Vector length, the number of elements in a "Vector", `SVSTATE.vl` may be set
+entirely dynamically at runtime from a number of sources. `setvl` is the primary
+instruction for setting Vector Length.
`setvl` is conceptually similar but different from the Cray, SX Aurora, and RISC-V RVV
equivalent. Similar to RVV, VL is set to be within
-the range 0 <= VL <= MVL
+the range 0 <= VL <= MVL. Unlike RVV, VL is set **exactly** according to the following:
- VL = rd = MIN(vlen, MVL)
+ VL = (RT|0) = MIN(vlen, MVL)
-where 0 <= MVL <= XLEN
+where 0 <= MVL <= 127 and vlen may come from an immediate, `RA`, or from the `CTR` SPR,
+depending on options selected with the `setvl` instruction.
+
+Programmer's Note: conceptual understanding of Cray-style Vectors is far beyond the scope
+of the Power ISA Technical Reference. Guidance on the 50-year-old Cray Vector paradigm is
+best sought elsewhere: good studies include Academic Courses given on the 1970s
+Cray Supercomputers over at least the past three decades.
**SUBVL - Sub Vector Length**
The main effect of SUBVL is that predication bits are applied per
**group**, rather than by individual element. Legal values are 0 to 3,
-representing 1 operation thru 4 operations respectively.
+representing 1 operation (1 element) thru 4 operations (4 elements) respectively.
+Elements are best though of in the context of 3D, Audio and Video: two Left and Right
+Channel "elements" or four ARGB "elements", or three XYZ coordinate "elements".
+
+`subvl` is again primarily set by the `setvl` instruction. Not to be confused
+with `hphint`.
+
+Directly related to `subvl` is the `pack` and `unpack` Mode bits of `SVSTATE`.
+See `svstep` instruction for how to set Pack and Unpack Modes.
+
**Horizontal Parallelism**
Field used in Simple-V to specify whether VL (vl in the SVSTATE SPR) is to be set
Formats: SVL
SVi (16:22)
- Simple-V immediate field for setting VL or MVL (vl, maxvl in the SVSTATE SPR)
+ Simple-V immediate field used by setvl for setting VL or MVL
+ (vl, maxvl in the SVSTATE SPR)
+ and used as a "Mode of Operation" selector in svstep
Formats: SVL
```
-
# Appendices
Appendix E Power ISA sorted by opcode
| Form | Book | Page | Version | mnemonic | Description |
|------|------|------|---------|----------|-------------|
| SVL | I | # | 3.0B | svstep | Vertical-First Stepping and status reporting |
+| SVL | I | # | 3.0B | setvl | Cray-like establishment of Looping (Vector) context |
+[[!tag opf_rfc]]
projects / libreriscv.git / blobdiff