-# 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
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
`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.
# 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
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 | 0b0 | EXT200-232 or `RESERVED2` (56-bit) |
-| PO9?| 0 | x | xxxx | 0b1 | EXT232-263 and SVP64(/V/S) |
+| 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.
|--------|---|---|-------|---------|
| 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
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
-
-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.
-
-```
- 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_matrix.py;hb=HEAD>
-
-## Parallel Reduction
+## 3D GPU style "Branch Conditional"
-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.
+(*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/>
```
- 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
+ 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_parallel_reduce.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>
## Big-Integer Math
-Remarkably, `sv.addeo` is inherently a big-integer Vector Add, using `CA`
+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
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.addeo *0, *2, *4
+ 37 sv.adde *0, *2, *4
```
A 128/64-bit shift may be used as a Vector shift by a Scalar amount, by merging
```
Additional 128/64 Mul and Div/Mod instructions may similarly be exploited
-to perform roll-over in arbitrary-length arithmetic.
+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>
projects / libreriscv.git / blobdiff