-# 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
Power ISA has a reputation as being long-term stable.
**Simple-V guarantees binary interoperability** by defining fixed
-register file bitwidths and size for all instructions.
+register file bitwidths and size for a given set of instructions.
The seduction of permitting different implementors to choose a register file
bitwidth and size with the same instructions unfortunately has
the catastrophic side-effect of introducing not only binary incompatibility
but silent data corruption as well as no means to trap-and-emulate differing
bitwidths.[^vsx256]
-"Silicon-Partner" Scalability is identical to mixing 32-bit Power ISA
-with 64-bit in the same binary (just as catastrophic), and
-is prohibited in the Simple-V Scalable Vector ISA,
-`RESERVED` space is thus crucial to have, in order
-to provide the option of
-future expanded register file bitwidths and sizes[^msr],
-under **explicitly-distinguishable** encoding,
-**at the discretion of the OPF ISA WG**,
-not the implementor ("Silicon Partner").
+"Silicon-Partner" Scalability is identical to attempting to run 64-bit
+Power ISA binaries without setting - or having `MSR.SF` - on "Scaled"
+32-bit hardware: **the same opcodes** were shared between 32 and 64 bit.
+`RESERVED` space is thus crucial
+to have, in order to provide the **OPF ISA WG** - not implementors
+("Silicon Partners") - with the option to properly review and decide
+any (if any) future expanded register file bitwidths and sizes[^msr],
+**under explicitly-distinguishable encodings** so as to guarantee
+long-term stability and binary interoperability.
# Hardware Implementations
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
microarchitecture. As usually becomes quickly apparent with in-order, its
limitations extend also to when Simple-V is deployed, which is why
Multi-Issue Out-of-Order is the recommended (but not mandatory) Scalar
-Micro-architecture.
+Micro-architecture. Byte-level write-enable regfiles (like SRAMs) are
+strongly recommended, to avoid a Read-Modify-Write cycle.
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 in reverse order).
+ "Reverse Gear" (running loops backwards).
* **vec2/3/4 "Packing" and "Unpacking"** (similar to VSX `vpack` and `vpkss`)
accessible in a way that is easier than REMAP, added for the same reasons
that drove `vpack` and `vpkss` etc. to be added: pixel, audio, and 3D
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.
It does have to be pointed out that there is huge pressure on the
Mode bits. There was therefore insufficient room, unlike the way that
EXT001 was designed, to provide "identifying bits" *without first partially
-decoding the Suffix*. This should in no way be conflated with or taken
-as an indicator that changing the meaning of the Suffix is performed
-or desirable.
+decoding the Suffix*.
Some considerable care has been taken to ensure that Decoding may be
performed in a strict forward-pipelined fashion that, aside from changes in
`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
-especially given the close interaction with CTR in hot-loops.
+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.
Also `SVLR` is introduced, which is a parallel twin of `LR`, and saving
and restoring of LR and SVLR may be deferred until the final decision
# LD/ST RM Modes
Traditional Vector ISAs have vastly more (and more complex) addressing
-modes: unit strided, element strided, Indexed, Structure Packing. All
-of these had to be jammed in on top of existing Scalar instructions
-**without modifying or adding new Scalar instructions**.
-A small conceptual
-"cheat" was therefore needed. The Immediate (D) is in some Modes
-multiplied by the element index, which gives us element-strided.
-For unit-strided the width of the operation (`ld`, 8 byte) is
-multiplied by the element index and *substituted* for "D" when
-the immediate, D, is zero. Modifications to support this
-"cheat" on top of pre-existing Scalar HDL (and Simulators)
-have both turned out to be minimal.[^mul]
-Also added was the option to perform signed or unsigned Effective
-Address calculation, which comes into play only on LD/ST Indexed,
-when elwidth overrides are used. Another quirk: `RA` is never
-allowed to have its width altered: it remains 64-bit, as it is
-the Base Address.
+modes than Scalar ISAs: unit strided, element strided, Indexed, Structure
+Packing. All of these had to be jammed in on top of existing Scalar
+instructions **without modifying or adding new Scalar instructions**.
+A small conceptual "cheat" was therefore needed. The Immediate (D)
+is in some Modes multiplied by the element index, which gives us
+element-strided. For unit-strided the width of the operation (`ld`,
+8 byte) is multiplied by the element index and *substituted* for "D"
+when the immediate, D, is zero. Modifications to support this "cheat"
+on top of pre-existing Scalar HDL (and Simulators) have both turned
+out to be minimal.[^mul] Also added was the option to perform signed
+or unsigned Effective Address calculation, which comes into play only
+on LD/ST Indexed, when elwidth overrides are used. Another quirk:
+`RA` is never allowed to have its width altered: it remains 64-bit,
+as it is the Base Address.
One confusing thing is the unfortunate naming of LD/ST Indexed and
REMAP Indexed: some care is taken in the spec to discern the two.
"bit-inversion" needed for address calculation and/or reordering
of elements. DCT in particular needs both bit-inversion *and
Gray-Coding* offsets (a complexity that often "justifies" full
-assmbler loop-unrolling). DCT/FFT REMAP **automatically** performs
+assembler loop-unrolling). DCT/FFT REMAP **automatically** performs
the required offset adjustment to get data loaded and stored in
the required order. Matrix REMAP can likewise perform up to 3
Dimensions of reordering (on both Immediate and Indexed), and
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.
making it possible to forward-plan
Issue, Memory access and Register Hazard Management
in Multi-Issue Micro-architectures.
+
If combined with Vertical-First then much more complex operations may exploit
-REMAP Schedules, such as Complex Number FFTs.
+REMAP Schedules, such as Complex Number FFTs, by using Scalar intermediary
+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, 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.
* **Parallel Reduction** REMAP, performs an automatic map-reduce using
*any suitable scalar operation*.
+All REMAP Schedules are Precise-Interruptible. No latency penalty is caused by
+the fact that the Schedule is Parallel-Reduction, for example. The operations
+are Issued (Deterministically) as **Scalar** operations and thus any latency
+associated with **Scalar** operation Issue exactly as in a **Scalar**
+Micro-architecture will result. Contrast this with a Standard Vector ISA
+where frequently there is either considerable interrupt latency due to
+requiring a Parallel Reduction to complete in full, or partial results
+to be discarded and re-started should a high-priority Interrupt occur
+in the middle.
+
Note that predication is possible on REMAP but is hard to use effectively.
It is often best to make copies of data (`VCOMPRESS`) then apply REMAP.
# 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]]
projects / libreriscv.git / blobdiff