-# OPF ISA WG External RFC LS001 v2 14Sep2022
+# OPF ISA WG External RFC LS001 v3 24mar2023
* RFC Author: Luke Kenneth Casson Leighton.
* RFC Contributors/Ideas: Brad Frey, Paul Mackerras, Konstantinos Magritis,
[[ls001/discussion]]
This proposal is to extend the Power ISA with an Abstract RISC-Paradigm
-Vectorisation Concept that may be orthogonally applied to **all and any** suitable
-Scalar instructions, present and future, in the Scalar Power ISA.
+Vectorisation Concept that may be orthogonally applied to **all and any**
+suitable Scalar instructions, present and future, in the Scalar Power ISA.
The Vectorisation System is called
["Simple-V"](https://libre-soc.org/openpower/sv/)
and the Prefix Format is called
Stakeholder, is to bring to market mass-volume general-purpose compute
processors that are competitive in the 3D GPU Audio Visual DSP EDGE IoT
desktop chromebook netbook smartphone laptop markets, performance-leveraged
-by Simple-V. Simple-V thus has to
-be accompanied by corresponding **Scalar** instructions that bring the
-**Scalar** Power ISA up-to-date. These include IEEE754
+by Simple-V. To achieve this goal both Simple-V and accompanying
+**Scalar** Power ISA instructions are needed. These include IEEE754
[Transcendentals](https://libre-soc.org/openpower/transcendentals/)
[AV](https://libre-soc.org/openpower/sv/av_opcodes/)
cryptographic
[Biginteger](https://libre-soc.org/openpower/sv/biginteger/) and
[bitmanipulation](https://libre-soc.org/openpower/sv/bitmanip)
-operations that ARM
-Intel AMD and many other ISAs have been adding over the past 12 years
-and Power ISA has not. Three additional FP-related sets are needed
+operations present in ARM
+Intel AMD and many other ISAs.
+Three additional FP-related sets are needed
(missing from SFFS) -
[int_fp_mv](https://libre-soc.org/openpower/sv/int_fp_mv/)
[fclass](https://libre-soc.org/openpower/sv/fclass/) and
[crweird](https://libre-soc.org/openpower/sv/cr_int_predication/)
increase the capability of CR Fields.
-*Thus it becomes necesary to consider the Architectural Resource
+*Thus as the primary motivation is to create a **Hybrid 3D CPU-GPU-VPU ISA**
+it becomes necesary to consider the Architectural Resource
Allocation of not just Simple-V but the 80-100 Scalar instructions all
at the same time*.
Vector ISA pseudocode encountered the Vector operations were expressed
as a for-loop on a Scalar element
operation, and then both a Scalar **and** a Vector instruction was added.
-With Zero-Overhead Looping *already* being mainstream in DSPs for over three
+With
+[Zero-Overhead Looping](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
+*already* being common for over four
decades it felt natural to separate the looping at both the ISA and
the Hardware Level
and thus provide only Scalar instructions (instantly halving the number
The fundamental principle of Simple-V is that it sits between Issue and
Decode, pausing the Program-Counter to service a "Sub-PC"
-hardware for-loop. This is very similar to "Zero-Overhead Loops"
+hardware for-loop. This is very similar to
+[Zero-Overhead Loops](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
in High-end DSPs (TI MSP Series).
Considerable effort has been expended to ensure that Simple-V is
The only major concern is in the upper SV Extension Levels: the Hazard
Management for increased number of Scalar Registers to 128 (in current
versions) but given that IBM POWER9/10 has VSX register numbering 64,
-and modern GPUs have 128, 256 amd even 512 registers this was deemed
+and modern GPUs have 128, 256 and even 512 registers this was deemed
acceptable. Strategies do exist in hardware for Hazard Management of
such large numbers of registers, even for Multi-Issue microarchitectures.
* A third 24-bits (third 2-bit XO) is strongly recommended to be `RESERVED`
such that future unforeseen capability is needed (although this may be
alternatively achieved with a mandatory PCR or MSR bit)
-* To hold all Vector Context, five SPRs are needed for userspace.
- If Supervisor and Hypervisor mode are to
- also support Simple-V they will correspondingly need five SPRs each.
+* To hold all Vector Context, four SPRs are needed.
(Some 32/32-to-64 aliases are advantageous but not critical).
* Five 6-bit XO (A-Form) "Management" instructions are needed. These are
Scalar 32-bit instructions and *may* be 64-bit-extended in future
Context-switching and no adverse latency, it may be considered to
be a "Sub-PC" and as such absolutely must be treated with the same
respect and priority as MSR and PC.
-* **SVSRR0** - identical in purpose to SRR0/1: storing SVSTATE on context-switch
- along-side MSR and PC.
* **SVSHAPE0-3** - these are 32-bit and may be grouped in pairs, they REMAP
(shape) the Vectors[^svshape]
* **SVLR** - again similar to LR for exactly the same purpose, SVSTATE
of the predicates provides all of the other types of operations
found in Vector ISAs (VEXTRACT, VINSERT etc) again with no need
to actually provide explicit such instructions.
-* **Saturation**. applies to **all** LD/ST and Arithmetic and Logical
+* **Saturation**. applies to **all** LD/ST and Arithmetic and Logical
operations (without adding explicit saturation ops)
* **Reduction and Prefix-Sum** (Fibonnacci Series) Modes, including a
"Reverse Gear" (running loops backwards).
solve the "SIMD Considered Harmful" stripmining problem from a Memory
Access perspective.
* **Data-Dependent Fail-First**: a 100% Deterministic extension of the LDST
- ffirst concept: first `Rc=1 BO test` failure terminates looping and
+ ffirst concept: first `Rc=1 BO test` failure terminates looping and
truncates VL to that exact point. Useful for implementing algorithms
such as `strcpy` in around 14 high-performance Vector instructions, the
option exists to include or exclude the failing element.
`BO` as a set) dictate that the Branch should take place on either 'ALL'
tests succeeding (or failing) or whether 'SOME' tests succeed (or fail).
These options provide the ability to cover the majority of Parallel
-3D GPU Conditions, saving a not inconsiderable number of instructions
+3D GPU Conditions, saving up to **twelve** instructions
especially given the close interaction with CTR in hot-loops.[^parity]
[^parity]: adding a parity (XOR) option was too much. instead a parallel-reduction on `crxor` may be used in combination with a Scalar Branch.
nested VF Loops.
Simple-V Vertical-First Looping requires an explicit instruction to
-move `SVSTATE` regfile offsets forward: `svstep`. An early version of
+move `SVSTATE` regfile offsets forward: `svstep`. An early version of
Vectorised
Branch-Conditional attempted to merge the functionality of `svstep`
into `sv.bc`: it became CISC-like in its complexity and was quickly reverted.
If combined with Vertical-First then much more complex operations may exploit
REMAP Schedules, such as Complex Number FFTs, by using Scalar intermediary
-temporary registers to compute results that have a Vector destination.
+temporary registers to compute results that have a Vector source
+or destination or both.
Contrast this with a Standard Horizontal-First Vector ISA where the only
way to perform Vectorised Complex Arithmetic would be to add Complex Vector
-Arithmetic operations.
+Arithmetic operations, because due to the Horizontal (element-level)
+progression there is no way to utilise intermediary temporary (scalar)
+variables.[^complex]
+
+[^complex]: a case could be made for constructing Complex number arithmetic using multiple sequential Horizontal-First (Cray-style Vector) instructions. This may not be convenient in the least when REMAP is involved (such as Parallel Reduction of Complex Multiply).
* **DCT/FFT** REMAP brings more capability than TI's MSP-Series DSPs and
Qualcom Hexagon DSPs, and is not restricted to Integer or FP.
# Adding new opcodes.
-With Simple-V being a type of Zero-Overhead Loop Engine on top of
+With Simple-V being a type of
+[Zero-Overhead Loop](https://en.m.wikipedia.org/wiki/Zero-overhead_looping)
+Engine on top of
Scalar operations some clear guidelines are needed on how both
existing "Defined Words" (Public v3.1 Section 1.6.3 term) and future
Scalar operations are added within the 64-bit space. Examples of
allocated to Simple-V
* all other patterns are `RESERVED` for other non-Vectoriseable
purposes (just over 37.5%).
-
+
| 0-5 | 6 | 7 | 8-31 | 32:33 | Description |
|-----|---|---|-------|-------|----------------------------|
| PO9?| 0 | 0 | !zero | 00-10 | RESERVED (other) |
| 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
|-----|---|---|-------|------|---------------------------|
-| PO9?| 1 | 0 | 0000 | xx | `RESERVED1` or EXT300-363 |
-| PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 |
-| PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 |
-| PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 |
-
-Where:
+| PO9?| 1 | 0 | 0000 | xx | `RESERVED1` or EXT300-363 (32-bit) |
+| PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 (55-bit) |
+| PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 (55-bit) |
+| PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 (55-bit) |
* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
(but needs reserving as part of this RFC)
* QTY 3of 55-bit spaces also exist for future use (longer by 3 bits
than opcodes allocated in EXT001)
* Simple-V EXT2nn is restricted to range EXT248-263
-* non-Simple-V EXT2nn (if ever allocated by a future RFC) is restricted to range EXT200-247
+* non-Simple-V (non-Vectoriseable) EXT2nn (if ever requested in any future RFC) is restricted to range EXT200-247
* Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
+**This however potentially puts SVP64 under pressure (in 5-10 years).**
+Ideas being discussed already include adding LD/ST-with-Shift and variant
+Shift-Immediate operations that require large quantity of Primary Opcodes.
+To ensure that there is room in future,
+it may be better to allocate 25% to `RESERVED`:
+
+| 0-5 | 6 | 7 | 8-31 | 32| Description |
+|-----|---|---|-------|---|------------------------------------|
+| PO9?| 1 | 0 | 0000 | x | EXT300-363 or `RESERVED1` (32-bit) |
+| PO9?| 0 | x | xxxx | 0 | EXT200-232 or `RESERVED2` (56-bit) |
+| PO9?| 0 | x | xxxx | 1 | EXT232-263 and SVP64(/V/S) |
+
The clear separation between Simple-V and non-Simple-V stops
conflict in future RFCs, both of which get plenty of space.
EXT000-063 pressure is reduced in both Vectoriseable and
|--------|---|---|-------|---------|
| PO (9)?| 1 | 1 | nnnn | SVP64:{EXT000-063} |
-**{EXT248-263}** bit6=new bit7=scalar
+**{EXT232-263}** bit6=new bit7=scalar
This encoding represents the opportunity to introduce EXT248-263.
It is a Scalar-word encoding, and does not require implementing
SVP64 or SVP64-Single, but does require the Vector-space to be allocated.
-PO2 is in the range 0b11000 to 0b111111 to represent EXT248-263 respectively.
+PO2 is in the range 0b100000 to 0b1111111 to represent EXT232-263 respectively.
-| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | 0000 | 0b11 |PO2[2:5] | {EXT248-263} |
+| 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 0 | 0000 | 1 |PO2[1:5] | {EXT232-263} |
-**SVP64Single:{EXT248-263}** bit6=new bit7=scalar
+**SVP64Single:{EXT232-263}** bit6=new bit7=scalar
This encoding, which is effectively "implicit VL=1"
and comprising (from bits 8-31 being non-zero)
*at least some* form of Augmentation, it represents the opportunity
-to Augment EXT248-263 with the SVP64Single capabilities.
+to Augment EXT232-263 with the SVP64Single capabilities.
Must be allocated under Scalar *and* SVP64 simultaneously.
-| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 0 | !zero | 0b11 |PO2[2:5] | SVP64Single:{EXT248-263} |
+| 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 0 | !zero | 1 |PO2[1:5] | SVP64Single:{EXT232-263} |
**SVP64:{EXT248-263}** bit6=new bit7=vector
VL=1 may occur dynamically
at runtime, even when bits 8-31 are zero.
-| 0-5 | 6 | 7 | 8-31 | 32-3 | 34-37 | 38-63 |
-|--------|---|---|-------|------|---------|---------|
-| PO (9)?| 0 | 1 | nnnn | 0b11 |PO2[2:5] | SVP64:{EXT248-263} |
+| 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | 1 | nnnn | 1 |PO2[1:5] | SVP64:{EXT232-263} |
-**RESERVED2 / EXT300-363** bit6=old bit7=scalar
+**RESERVED1 / EXT300-363** bit6=old bit7=scalar
-This is entirely at the discretion of the ISA WG. Libre-SOC is *not*
-proposing the addition of EXT300-363: it is merely a possibility for
-future. The reason the space is not needed is because this is within
-the realm of Scalar-extended (SVP64Single), and with the 24-bit prefix
-area being all-zero (bits 8-31) this is defined as "having no augmentation"
-(in the Simple-V Specification it is termed `Scalar Identity Behaviour`).
-This in turn makes this prefix a *degenerate duplicate* so may be allocated
-for other purposes.
+This is at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT300-363: it is merely a possibility
| 0-5 | 6 | 7 | 8-31 | 32-63 |
|--------|---|---|-------|---------|
| PO (9)?| 1 | 0 | 0000 | EXT300-363 or `RESERVED1` |
+**RESERVED2 / EXT200-231** bit6=new bit32=1
+
+This is at the discretion of the ISA WG. Libre-SOC is *not*
+proposing the addition of EXT200-231: it is merely a possibility
+
+| 0-5 | 6 | 7 | 8-31 | 32 | 33-37 | 38-63 |
+|--------|---|---|-------|----|---------|---------|
+| PO (9)?| 0 | x | nnnn | 1 |PO2[1:5] | {EXT200-231} |
+
\newpage{}
# Example Legal Encodings and RESERVED spaces
| 64bit | ss.fishmv | 0x24!zero | 0x12345678| scalar SVP64Single:EXT2nn |
| 64bit | sv.fishmv | 0x25nnnnnn | 0x12345678| vector SVP64:EXT2nn |
-Here the encodings are the same, 0x12345678 means the same thing in
+Here the encodings are the same, 0x12345678 means the same thing in
all cases. Anything other than this risks either damage (truncation
of capabilities of Simple-V) or far greater complexity in the
Decode Phase.
EXT2nn POs right
across the board
(in the Scalar Suffix side, irrespective of Prefix), some allocated
-to Simple-V, some not.
+to Simple-V, some not.
**illegal due to missing**
Both of these Simple-V operations are illegally-allocated. The fact that
there does not exist a scalar "Defined Word" (even for EXT200-263) - the
unallocated block - means that the instruction may **not** be allocated in
-the Simple-V space.
+the Simple-V space.
**illegal attempt to put Scalar EXT004 into Vector EXT2nn**
This is not just illegal it is not even possible to achieve.
If attempted, by dropping EXT004 into bits 32-37, the top two
MSBs are actually *zero*, and the Vector EXT2nn space is only
-legal for Primary Opcodes in the range 248-263, where the top
+legal for Primary Opcodes in the range 232-263, where the top
two MSBs are 0b11. Thus this faulty attempt actually falls
unintentionally
into `RESERVED` "Non-Vectoriseable" Encoding space.
<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_predication.py;hb=HEAD>
-## 3D GPU style "Branch Conditional"
+## Matrix Multiply
-(*Note: Specification is ready, Simulator still under development of
-full specification capabilities*)
-This example demonstrates a 2-long Vector Branch-Conditional only
-succeeding if *all* elements in the Vector are successful. This
-avoids the need for additional instructions that would need to
-perform a Parallel Reduction of a Vector of Condition Register
-tests down to a single value, on which a Scalar Branch-Conditional
-could then be performed. Full Rationale at
-<https://libre-soc.org/openpower/sv/branches/>
+Matrix Multiply of any size (non-power-2) up to a total of 127 operations
+is achievable with only three instructions. Normally in any other SIMD
+ISA at least one source requires Transposition and often massive rolling
+repetition of data is required. These 3 instructions may be used as the
+"inner triple-loop kernel" of the usual 6-loop Massive Matrix Multiply.
```
- 80 # test_sv_branch_cond_all
- 81 for i in [7, 8, 9]:
- 83 addi 1, 0, i+1 # set r1 to i
- 84 addi 2, 0, i # set r2 to i
- 85 cmpi cr0, 1, 1, 8 # compare r1 with 8 and store to cr0
- 86 cmpi cr1, 1, 2, 8 # compare r2 with 8 and store to cr1
- 87 sv.bc/all 12, *1, 0xc # bgt 0xc - branch if BOTH
- 88 # r1 AND r2 greater 8 to the nop below
- 89 addi 3, 0, 0x1234, # if tests fail this shouldn't execute
- 90 or 0, 0, 0 # branch target
+ 28 # test_sv_remap1 5x4 by 4x3 matrix multiply
+ 29 svshape 5, 4, 3, 0, 0
+ 30 svremap 31, 1, 2, 3, 0, 0, 0
+ 31 sv.fmadds *0, *8, *16, *0
```
-<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bc.py;hb=HEAD>
+<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;hb=HEAD>
+
+## Parallel Reduction
+
+Parallel (Horizontal) Reduction is often deeply problematic in SIMD and
+Vector ISAs. Parallel Reduction is Fully Deterministic in Simple-V and
+thus may even usefully be deployed on non-associative and non-commutative
+operations.
+
+```
+ 75 # test_sv_remap2
+ 76 svshape 7, 0, 0, 7, 0
+ 77 svremap 31, 1, 0, 0, 0, 0, 0 # different order
+ 78 sv.subf *0, *8, *16
+```
+
+<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_parallel_reduce.py;hb=HEAD>
\newpage{}
## DCT
<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;hb=HEAD>
-## Matrix Multiply
+## 3D GPU style "Branch Conditional"
-Matrix Multiply of any size (non-power-2) up to a total of 127 operations
-is achievable with only three instructions. Normally in any other SIMD
-ISA at least one source requires Transposition and often massive rolling
-repetition of data is required. These 3 instructions may be used as the
-"inner triple-loop kernel" of the usual 6-loop Massive Matrix Multiply.
+(*Note: Specification is ready, Simulator still under development of
+full specification capabilities*)
+This example demonstrates a 2-long Vector Branch-Conditional only
+succeeding if *all* elements in the Vector are successful. This
+avoids the need for additional instructions that would need to
+perform a Parallel Reduction of a Vector of Condition Register
+tests down to a single value, on which a Scalar Branch-Conditional
+could then be performed. Full Rationale at
+<https://libre-soc.org/openpower/sv/branches/>
```
- 28 # test_sv_remap1 5x4 by 4x3 matrix multiply
- 29 svshape 5, 4, 3, 0, 0
- 30 svremap 31, 1, 2, 3, 0, 0, 0
- 31 sv.fmadds *0, *8, *16, *0
+ 80 # test_sv_branch_cond_all
+ 81 for i in [7, 8, 9]:
+ 83 addi 1, 0, i+1 # set r1 to i
+ 84 addi 2, 0, i # set r2 to i
+ 85 cmpi cr0, 1, 1, 8 # compare r1 with 8 and store to cr0
+ 86 cmpi cr1, 1, 2, 8 # compare r2 with 8 and store to cr1
+ 87 sv.bc/all 12, *1, 0xc # bgt 0xc - branch if BOTH
+ 88 # r1 AND r2 greater 8 to the nop below
+ 89 addi 3, 0, 0x1234, # if tests fail this shouldn't execute
+ 90 or 0, 0, 0 # branch target
```
-<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;hb=HEAD>
+<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bc.py;hb=HEAD>
-## Parallel Reduction
+## Big-Integer Math
-Parallel (Horizontal) Reduction is often deeply problematic in SIMD and
-Vector ISAs. Parallel Reduction is Fully Deterministic in Simple-V and
-thus may even usefully be deployed on non-associative and non-commutative
-operations.
+Remarkably, `sv.adde` is inherently a big-integer Vector Add, using `CA`
+chaining between **Scalar** operations.
+Using Vector LD/ST and recalling that the first and last `CA` may
+be chained in and out of an entire **Vector**, unlimited-length arithmetic is
+possible.
```
- 75 # test_sv_remap2
- 76 svshape 7, 0, 0, 7, 0
- 77 svremap 31, 1, 0, 0, 0, 0, 0 # different order
- 78 sv.subf *0, *8, *16
- 79
- 80 REMAP sv.subf RT,RA,RB - inverted application of RA/RB
- 81 left/right due to subf
+ 26 # test_sv_bigint_add
+ 32
+ 33 r3/r2: 0x0000_0000_0000_0001 0xffff_ffff_ffff_ffff +
+ 34 r5/r4: 0x8000_0000_0000_0000 0x0000_0000_0000_0001 =
+ 35 r1/r0: 0x8000_0000_0000_0002 0x0000_0000_0000_0000
+ 36
+ 37 sv.adde *0, *2, *4
```
-<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_parallel_reduce.py;hb=HEAD>
+A 128/64-bit shift may be used as a Vector shift by a Scalar amount, by merging
+two 64-bit consecutive registers in succession.
+
+```
+ 62 # test_sv_bigint_scalar_shiftright(self):
+ 64
+ 65 r3 r2 r1 r4
+ 66 0x0000_0000_0000_0002 0x8000_8000_8000_8001 0xffff_ffff_ffff_ffff >> 4
+ 67 0x0000_0000_0000_0002 0x2800_0800_0800_0800 0x1fff_ffff_ffff_ffff
+ 68
+ 69 sv.dsrd *0,*1,4,1
+```
+
+Additional 128/64 Mul and Div/Mod instructions may similarly be exploited
+to perform roll-over in arbitrary-length arithmetic: effectively they use
+one of the two 64-bit output registers as a form of "64-bit Carry In-Out".
+
+All of these big-integer instructions are Scalar instructions standing on
+their own merit and may be utilised even in a Scalar environment to improve
+performance. When used with Simple-V they may also be used to improve
+performance and also greatly simplify unlimited-length biginteger algorithms.
+
+<https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_bigint.py;hb=HEAD>
[[!tag opf_rfc]]