# 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**:
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, instead having the legacy
-"PackedSIMD" paradigm. Fortunately this presents
-the opportunity to modernise Power ISA learning from both past ISA features and
-mistakes placing it far above the top of Supercomputing for the next two decades
-and beyond.
+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. 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 the Sequential Programming Execution
- Model.
+ 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
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. Normal reductions
- expected are of the order of 5 to 10% being considered a highly worthwhile exercise
- to pursue inclusion. not fractions of former sizes.
-4. Other potential extensions include work inspired by EXTRA-V and Eth-Zurich "Snitch"
- to reduce CPU workload by 95% in the case of EXTRA-V and power consumption by
- 85% in the case of Snitch. Addition massive reductions from ZOLC Research are
- also anticipated.
+ ISA Extension added to any ISA in the history of Computing.
**Changes**
# Notation, Section 1.3.2
-When register operands (RA, RT, BF) are prefixed by a single underscore
-(_RT, _RA, _BF) the variable contains the contents of the instruction field
-not the contents of the Register File referenced *by* that field. Example:
-`_RT` contains the contents of bits 5 thru 10. The relationship
-`RT = GPR(_RT)` is thus always true. Uses include making alternative
-decisions within an instruction based on whether the operand field
-is zero or non-zero.
+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`)
----------------
\newpage{}
-# svstep: Vertical-First Stepping and status reporting
-
-SVL-Form
-
-* svstep RT,SVi,vf (Rc=0)
-* svstep. RT,SVi,vf (Rc=1)
-
-| 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 pack and unpack in SVSTATE
- SVSTATE[53] <- SVi[5]
- SVSTATE[54] <- SVi[6]
- RT <- [0]*62 || SVSTATE[53:54]
- else
- # Vertical-First explicit stepping.
- step <- SVSTATE_NEXT(SVi, vf)
- RT <- [0]*57 || step
-```
-
-Special Registers Altered:
-
- CR0 (if Rc=1)
-
--------------
-
-**svstep "Mode of Enquiry"**
-
-It is possible to
-
-* `SVi=0`: appropriately step srcstep, dststep, subsrcstep and subdststep to the next
- element, taking pack and unpack into consideration.
-* `SVi=1`: test inner middle and outer
- loop end conditions from SVSTATE0 and store in CR.EQ CR.LE CR.GT
-* `SVi=2`: test SVSTATE1 (and return conditions)
-* `SVi=3`: test SVSTATE2 (and return conditions)
-* `SVi=4`: test SVSTATE3 (and return conditions)
-* `SVi=5`: `SVSTATE.srcstep` is returned.
-* `SVi=6`: `SVSTATE.dststep` is returned.
-* `SVi=12`: `SVSTATE.pack` is set to zero and `SVSTATE.unpack` set to zero
-* `SVi=13`: `SVSTATE.pack` is set to zero and `SVSTATE.unpack` set to zero
-* `SVi=14`: `SVSTATE.pack` is set to zero and `SVSTATE.unpack` set to zero
-* `SVi=15`: `SVSTATE.pack` is set to zero and `SVSTATE.unpack` set to zero
-
-\newpage{}
-
-
-# setvl
-
-SVL-Form
-
-| 0-5|6-10|11-15|16-22 | 23 24 25 | 26-30 |31| FORM |
-| -- | -- | --- | ---- |----------| ----- |--|----------|
-|PO | RT | RA | SVi | ms vs vf | XO |Rc| SVL-Form |
-
-* setvl RT,RA,SVi,vf,vs,ms (Rc=0)
-* setvl. RT,RA,SVi,vf,vs,ms (Rc=1)
-
-Pseudo-code:
-
-```
- overflow <- 0b0 # sets CR.SO if set and if Rc=1
- 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
- # MAXVL is a static "state-reset" opportunity so VF is only set then.
- if ms = 1 then
- SVSTATE[63] <- vf # set Vertical-First mode
- SVSTATE[62] <- 0b0 # clear persist bit
-```
-
-Special Registers Altered:
-
-```
- CR0 (if Rc=1)
-```
-
-* `SVi` - bits 16-22 - an immediate operand for setting MVL and/or VL
-* `ms` - bit 23 - allows for setting of MVL
-* `vs` - bit 24 - allows for setting of VL
-* `vf` - bit 25 - sets "Vertical First Mode".
-
-Note that in immediate setting mode VL and MVL start from **one**
-but that this is compensated for in the assembly notation.
-i.e. that an immediate value of 1 in assembler notation
-actually places the value 0b0000000 in the `SVi` field bits:
-on execution the `setvl` instruction adds one to the decoded
-`SVi` field bits, resulting in
-VL/MVL being set to 1. This allows VL to be set to values
-ranging from 1 to 128 with only 7 bits instead of 8.
-Setting VL/MVL
-to 0 would result in all Vector operations becoming `nop`. If this is
-truly desired (nop behaviour) then setting VL and MVL to zero is to be
-done via the [[SVSTATE SPR|sv/sprs]].
-
-Note that setmvli is a pseudo-op, based on RA/RT=0, and setvli likewise
-
- setvli VL=8 : setvl r0, r0, VL=8, vf=0, vs=1, ms=0
- setvli. VL=8 : setvl. r0, r0, VL=8, vf=0, vs=1, ms=0
- setmvli MVL=8 : setvl r0, r0, MVL=8, vf=0, vs=0, ms=1
- setmvli. MVL=8 : setvl. r0, r0, MVL=8, vf=0, vs=0, ms=1
-
-Additional pseudo-op for obtaining VL without modifying it (or any state):
-
- getvl r5 : setvl r5, r0, vf=0, vs=0, ms=0
- getvl. r5 : setvl. r5, r0, vf=0, vs=0, ms=0
-
-Note that whilst it is possible to set both MVL and VL from the same
-immediate, it is not possible to set them to different immediates in
-the same instruction. Doing so would require two instructions.
-
-**Selecting sources for VL**
-
-There is considerable opcode pressure, consequently to set MVL and VL
-from different sources is as follows:
-
-| condition | effect |
-| - | - |
-| `vs=1, RA=0, RT!=0` | VL,RT set to MIN(MVL, CTR) |
-| `vs=1, RA=0, RT=0` | VL set to MIN(MVL, SVi+1) |
-| `vs=1, RA!=0, RT=0` | VL set to MIN(MVL, RA) |
-| `vs=1, RA!=0, RT!=0` | VL,RT set to MIN(MVL, RA) |
-
-The reasoning here is that the opportunity to set RT equal to the
-immediate `SVi+1` is sacrificed in favour of setting from CTR.
-
-# Unusual Rc=1 behaviour
-
-Normally, the return result from an instruction is in `RT`. With
-it being possible for `RT=0` to mean that `CTR` mode is to be read,
-some different semantics are needed.
-
-CR Field 0, when `Rc=1`, may be set even if `RT=0`. The reason is that
-overflow may occur: `VL`, if set either from an immediate or from `CTR`,
-may not exceed `MAXVL`, and if it is, `CR0.SO` must be set.
-
-Additionally, in reality it is **`VL`** being set. Therefore, rather
-than `CR0` testing `RT` when `Rc=1`, CR0.EQ is set if `VL=0`, CR0.GE
-is set if `VL` is non-zero.
-
-# Vertical First Mode
-
-Vertical First is effectively like an implicit single bit predicate
-applied to every SVP64 instruction. **ONLY** one element in each
-SVP64 Vector instruction is executed; srcstep and dststep do **not**
-increment, and the Program Counter progresses **immediately** to
-the next instruction just as it would for any standard scalar v3.0B
-instruction.
-
-An explicit mode of setvl is called which can move srcstep and
-dststep on to the next element, still respecting predicate
-masks.
-
-In other words, where normal SVP64 Vectorisation acts "horizontally"
-by looping first through 0 to VL-1 and only then moving the PC
-to the next instruction, Vertical-First moves the PC onwards
-(vertically) through multiple instructions **with the same
-srcstep and dststep**, then an explict instruction used to
-advance srcstep/dststep. An outer loop is expected to be
-used (branch instruction) which completes a series of
-Vector operations.
-
-```svfstep``` mode is enabled when vf=1, vs=0 and ms=0.
-When Rc=1 it is possible to determine when any level of
-loops reach an end condition, or if VL has been reached. The immediate can
-be reinterpreted as indicating which SVSTATE (0-3)
-should be tested and placed into CR0 (when Rc=1)
-
-When RT is not zero, an internal stepping index may also be returned,
-either the REMAP index or srcstep or dststep. This table is identical
-to that of [[sv/svstep]]:
-
-* `SVi=1`: also include inner middle and outer
- loop end conditions from SVSTATE0 into CR.EQ CR.LE CR.GT
-* `SVi=2`: test SVSTATE1 (and return conditions)
-* `SVi=3`: test SVSTATE2 (and return conditions)
-* `SVi=4`: test SVSTATE3 (and return conditions)
-* `SVi=5`: `SVSTATE.srcstep` is returned.
-* `SVi=6`: `SVSTATE.dststep` is returned.
-
-Testing any end condition of any loop of any REMAP state allows branches to be used to create loops.
-
-*Programmers should be aware that VL, srcstep and dststep are global in nature.
-Nested looping with different schedules is perfectly possible, as is
-calling of functions, however SVSTATE (and any associated SVSTATE) should be stored on the stack.*
-
-**SUBVL**
-
-Sub-vector elements are not be considered "Vertical". The vec2/3/4
-is to be considered as if the "single element". Caveats exist for
-[[sv/mv.swizzle]] and [[sv/mv.vec]] when Pack/Unpack is enabled,
-due to the order in which VL and SUBVL loops are applied being
-swapped (outer-inner becomes inner-outer)
-
-# Examples
-
-## Core concept loop
-
-```
-loop:
- setvl a3, a0, MVL=8 # update a3 with vl
- # (# of elements this iteration)
- # set MVL to 8
- # do vector operations at up to 8 length (MVL=8)
- # ...
- sub a0, a0, a3 # Decrement count by vl
- bnez a0, loop # Any more?
-```
-
-## Loop using Rc=1
-
- my_fn:
- li r3, 1000
- b test
- loop:
- sub r3, r3, r4
- ...
- test:
- setvli. r4, r3, MVL=64
- bne cr0, loop
- end:
- blr
-
-## Load/Store-Multi (selective)
-
-Up to 64 FPRs will be loaded, here. `r3` is set one per bit
-for each FP register required to be loaded. The block of memory
-from which the registers are loaded is contiguous (no gaps):
-any FP register which has a corresponding zero bit in `r3`
-is *unaltered*. In essence this is a selective LD-multi with
-"Scatter" capability.
-
- setvli r0, MVL=64, VL=64
- sv.fld/dm=r3 *r0, 0(r30) # selective load 64 FP registers
-
-Up to 64 FPRs will be saved, here. Again, `r3`
-
- setvli r0, MVL=64, VL=64
- sv.stfd/sm=r3 *fp0, 0(r30) # selective store 64 FP registers
-
--------------
-
-\newpage{}
+[[!inline pages="openpower/sv/svstep" raw=yes ]]
+[[!inline pages="openpower/sv/setvl" raw=yes ]]
# SVSTATE SPR
| 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