# Introduction
Simple-V is a type of Vectorisation best described as a "Prefix Loop
-Subsystem" similar to the 5 decades-old Zilog Z80 `LDIR` instruction and to the 8086 `REP`
-Prefix instruction. More advanced features are similar to the Z80
-`CPIR` instruction. If viewed one-dimensionally as an actual Vector ISA it introduces
-over 1.5 million 64-bit Vector instructions. SVP64, the instruction
-format used by Simple-V, is therefore best viewed as an orthogonal RISC-paradigm "Prefixing"
-subsystem instead.
+Subsystem" similar to the 5 decades-old Zilog Z80 `LDIR` instruction and
+to the 8086 `REP` Prefix instruction. More advanced features are similar
+to the Z80 `CPIR` instruction. If viewed one-dimensionally as an actual
+Vector ISA it introduces over 1.5 million 64-bit Vector instructions.
+SVP64, the instruction format used by Simple-V, is therefore best viewed
+as an orthogonal RISC-paradigm "Prefixing" subsystem instead.
Except where explicitly stated all bit numbers remain as in the rest of
the Power ISA: in MSB0 form (the bits are numbered from 0 at the MSB on
## Register files, elements, and Element-width Overrides
-In the Upper Compliancy Levels of SVP64 the size of the GPR and FPR Register
-files are expanded from 32 to 128 entries, and the number of CR Fields
-expanded from CR0-CR7 to CR0-CR127. (Note: A future version of SVP64 is anticipated
-to extend the VSR register file).
+In the Upper Compliancy Levels of SVP64 the size of the GPR and FPR
+Register files are expanded from 32 to 128 entries, and the number of
+CR Fields expanded from CR0-CR7 to CR0-CR127. (Note: A future version
+of SVP64 is anticipated to extend the VSR register file).
Memory access remains exactly the same: the effects of `MSR.LE` remain
exactly the same, affecting as they already do and remain **only**
The top 32 MSBs in each new SVP64 Condition Register are *also* not used:
only the bottom 32 bits (numbered 32:63 in MSB0 numbering).
-*Programmer's note: using `sv.mfcr` without element-width overrides to take
-into account the fact that the top 32 MSBs are zero and thus effectively
-doubling the number of GPR registers required to hold all 128 CR Fields
-would seem the only option because normally elwidth overrides would
-halve the capacity of the instruction. However in this case it is
-possible to use destination element-width overrides (for `sv.mfcr`.
-source overrides would be used on the GPR of `sv.mtocrf`),
-whereupon truncation
-of the 64-bit Condition Register(s) occurs, throwing away the zeros and
-storing the remaining (valid, desired) 32-bit values sequentially into
-(LSB0-convention) lower-numbered and upper-numbered halves of GPRs respectively.
-The programmer is expected to be aware however that the full width of
-the entire 64-bit Condition Register is considered to be "an element".
-This is **not** like any other Condition-Register instructions because
-all other CR instructions, on closer investigation, will be observed
-to all be CR-bit or CR-Field related. Thus a `VL` of 16 must be used*
+*Programmer's note: using `sv.mfcr` without element-width overrides
+to take into account the fact that the top 32 MSBs are zero and thus
+effectively doubling the number of GPR registers required to hold all 128
+CR Fields would seem the only option because normally elwidth overrides
+would halve the capacity of the instruction. However in this case it
+is possible to use destination element-width overrides (for `sv.mfcr`.
+source overrides would be used on the GPR of `sv.mtocrf`), whereupon
+truncation of the 64-bit Condition Register(s) occurs, throwing away
+the zeros and storing the remaining (valid, desired) 32-bit values
+sequentially into (LSB0-convention) lower-numbered and upper-numbered
+halves of GPRs respectively. The programmer is expected to be aware
+however that the full width of the entire 64-bit Condition Register
+is considered to be "an element". This is **not** like any other
+Condition-Register instructions because all other CR instructions,
+on closer investigation, will be observed to all be CR-bit or CR-Field
+related. Thus a `VL` of 16 must be used*
## Future expansion.
# New 64-bit Instruction Encoding spaces
-The following seven new areas are defined within Primary Opcode 9 (EXT009) as a
-new 64-bit encoding space, alongside EXT1xx.
+The following seven new areas are defined within Primary Opcode 9 (EXT009)
+as a new 64-bit encoding space, alongside EXT1xx.
| 0-5 | 6 | 7 | 8-31 | 32| Description |
|-----|---|---|-------|---|------------------------------------|
| PO | 1 | 0 | !zero | n | SVP64Single:EXT000-063 or `RESERVED4` |
| PO | 1 | 1 | nnnn | n | SVP64:EXT000-063 |
-Note that for the future SVP64Single Encoding (currently RESERVED3 and 4) it
-is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
-for which bits 8-31
-can be zero (termed `scalar identity behaviour`). This
-prohibition allows SVP64Single to share its
-Encoding space with Scalar Ext232-263 and Scalar EXT300-363.
+Note that for the future SVP64Single Encoding (currently RESERVED3 and 4)
+it is prohibited to have bits 8-31 be zero, unlike for SVP64 Vector space,
+for which bits 8-31 can be zero (termed `scalar identity behaviour`). This
+prohibition allows SVP64Single to share its Encoding space with Scalar
+Ext232-263 and Scalar EXT300-363.
Also that RESERVED1 and 2 are candidates for future Major opcode
areas EXT200-231 and EXT300-363 respectively, however as RESERVED areas
# Remapped Encoding (`RM[0:23]`)
-In the SVP64 Vector Prefix spaces, the 24 bits 8-31 are termed `RM`. Bits 32-37 are
-the Primary Opcode of the Suffix "Defined Word". 38-63 are the remainder of the
-Defined Word. Note that the new EXT232-263 SVP64 area it is obviously mandatory
-that bit 32 is required to be set to 1.
+In the SVP64 Vector Prefix spaces, the 24 bits 8-31 are termed `RM`. Bits
+32-37 are the Primary Opcode of the Suffix "Defined Word". 38-63 are the
+remainder of the Defined Word. Note that the new EXT232-263 SVP64 area
+it is obviously mandatory that bit 32 is required to be set to 1.
| 0-5 | 6 | 7 | 8-31 | 32-37 | 38-64 |Description |
|-----|---|---|----------|--------|----------|-----------------------|
| PO | 1 | 1 | RM[0:23] | nnnnnn | xxxxxxxx | SVP64:EXT000-063 |
It is important to note that unlike v3.1 64-bit prefixed instructions
-there is insufficient space in `RM` to provide identification of any SVP64
-Fields without first partially decoding the 32-bit suffix. Similar to
-the "Forms" (X-Form, D-Form) the `RM` format is individually associated
-with every instruction. However this still does not adversely affect Multi-Issue
-Decoding because the identification of the *length* of anything in the
-64-bit space has been kept brutally simple (EXT009), and further decoding
-of any number of 64-bit Encodings in parallel at that point is fully independent.
+there is insufficient space in `RM` to provide identification of
+any SVP64 Fields without first partially decoding the 32-bit suffix.
+Similar to the "Forms" (X-Form, D-Form) the `RM` format is individually
+associated with every instruction. However this still does not adversely
+affect Multi-Issue Decoding because the identification of the *length*
+of anything in the 64-bit space has been kept brutally simple (EXT009),
+and further decoding of any number of 64-bit Encodings in parallel at
+that point is fully independent.
Extreme caution and care must be taken when extending SVP64
in future, to not create unnecessary relationships between prefix and
[`bf16`](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
is reserved for a future implementation of SV
-Note that any IEEE754 FP operation in Power ISA ending in "s" (`fadds`) shall
-perform its operation at **half** the ELWIDTH then padded back out
-to ELWIDTH. `sv.fadds/ew=f32` shall perform an IEEE754 FP16 operation that is then "padded" to fill out to an IEEE754 FP32. When ELWIDTH=DEFAULT
+Note that any IEEE754 FP operation in Power ISA ending in "s" (`fadds`)
+shall perform its operation at **half** the ELWIDTH then padded back out
+to ELWIDTH. `sv.fadds/ew=f32` shall perform an IEEE754 FP16 operation
+that is then "padded" to fill out to an IEEE754 FP32. When ELWIDTH=DEFAULT
clearly the behaviour of `sv.fadds` is performed at 32-bit accuracy
then padded back out to fit in IEEE754 FP64, exactly as for Scalar
-v3.0B "single" FP. Any FP operation ending in "s" where ELWIDTH=f16
-or ELWIDTH=bf16 is reserved and must raise an illegal instruction
-(IEEE754 FP8 or BF8 are not defined).
+v3.0B "single" FP. Any FP operation ending in "s" where ELWIDTH=f16 or
+ELWIDTH=bf16 is reserved and must raise an illegal instruction (IEEE754
+FP8 or BF8 are not defined).
### Elwidth for CRs (no meaning)
or max of a signed result, and for FP to the min and max value rather
than returning +/- INF.
-When Rc=1, the CR "overflow" bit is set on the CR associated with the
-element, to indicate whether saturation occurred. Note that due to
-the hugely detrimental effect it has on parallel processing, XER.SO is
-**ignored** completely and is **not** brought into play here. The CR
-overflow bit is therefore simply set to zero if saturation did not occur,
-and to one if it did. This behaviour (ignoring XER.SO) is actually optional in
-the SFFS Compliancy Subset: for SVP64 it is made mandatory *but only on
-Vectorised instructions*.
+When Rc=1, the CR "overflow" bit is set on the CR associated with
+the element, to indicate whether saturation occurred. Note that
+due to the hugely detrimental effect it has on parallel processing,
+XER.SO is **ignored** completely and is **not** brought into play here.
+The CR overflow bit is therefore simply set to zero if saturation did
+not occur, and to one if it did. This behaviour (ignoring XER.SO) is
+actually optional in the SFFS Compliancy Subset: for SVP64 it is made
+mandatory *but only on Vectorised instructions*.
Note also that saturate on operations that set OE=1 must raise an Illegal
-Instruction due to the conflicting use of the CR.so bit for storing if
-saturation occurred. Vectorised Integer Operations that produce a Carry-Out (CA,
-CA32): these two bits will be `UNDEFINED` if saturation is also requested.
+Instruction due to the conflicting use of the CR.so bit for storing
+if saturation occurred. Vectorised Integer Operations that produce a
+Carry-Out (CA, CA32): these two bits will be `UNDEFINED` if saturation
+is also requested.
Note that the operation takes place at the maximum bitwidth (max of
src and dest elwidth) and that truncation occurs to the range of the
*0,*0,*0`, which is not a `nop` because it allows Fail-First Mode to
perform a test and truncate VL.*
-*Hardware implementor's note: effective Sequential Program Order must be preserved.
-Speculative Execution is perfectly permitted as long as the speculative elements
-are held back from writing to register files (kept in Resevation Stations),
-until such time as the relevant
-CR Field bit(s) has been analysed. All Speculative elements sequentially beyond the
-test-failure point **MUST** be cancelled. This is no different from standard
-Out-of-Order Execution and the modification effort to efficiently support
-Data-Dependent Fail-First within a pre-existing Multi-Issue Out-of-Order Engine
-is anticipated to be minimal. In-Order systems on the other hand are expected,
-unavoidably, to be low-performance*.
+*Hardware implementor's note: effective Sequential Program Order must
+be preserved. Speculative Execution is perfectly permitted as long as
+the speculative elements are held back from writing to register files
+(kept in Resevation Stations), until such time as the relevant CR Field
+bit(s) has been analysed. All Speculative elements sequentially beyond
+the test-failure point **MUST** be cancelled. This is no different from
+standard Out-of-Order Execution and the modification effort to efficiently
+support Data-Dependent Fail-First within a pre-existing Multi-Issue
+Out-of-Order Engine is anticipated to be minimal. In-Order systems on
+the other hand are expected, unavoidably, to be low-performance*.
Two extremely important aspects of ffirst are:
Memory Operations as well.
Vectorised Load and Store also presents an extra dimension (literally)
-which creates scenarios unique to Vector applications, that a Scalar
-(and even a SIMD) ISA simply never encounters. SVP64 endeavours to add
-the modes typically found in *all* Scalable Vector ISAs, without changing
-the behaviour of the underlying Base (Scalar) v3.0B operations in any way.
-(The sole apparent exception is Post-Increment Mode on LD/ST-update instructions)
+which creates scenarios unique to Vector applications, that a Scalar (and
+even a SIMD) ISA simply never encounters. SVP64 endeavours to add the
+modes typically found in *all* Scalable Vector ISAs, without changing the
+behaviour of the underlying Base (Scalar) v3.0B operations in any way.
+(The sole apparent exception is Post-Increment Mode on LD/ST-update
+instructions)
## Modes overview
projects / libreriscv.git / commitdiff