-# 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
processors that are competitive in the 3D GPU Audio Visual DSP EDGE IoT
desktop chromebook netbook smartphone laptop markets, performance-leveraged
by Simple-V. To achieve this goal both Simple-V and accompanying
-Scalar** Power ISA instructions are needed. These include IEEE754
+**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
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.
## 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
projects / libreriscv.git / blobdiff