+[[!tag standards]]
+
# SVP64 for OpenPOWER ISA v3.0B
+**DRAFT STATUS**
+
This document describes [[SV|sv]] augmentation of the [[OpenPOWER|openpower]] v3.0B [[ISA|openpower/isa/]]. Permission to create commercial v3.1B implementations has not yet been granted through the issuance of a v3.1B EULA by the [[!wikipedia OpenPOWER_Foundation]] (only v3.0B)
Links:
* [[svp64/appendix]]
* <http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-December/001650.html>
* <https://bugs.libre-soc.org/show_bug.cgi?id=550>
+* <https://bugs.libre-soc.org/show_bug.cgi?id=573> TODO elwidth "infinite" discussion
+* <https://bugs.libre-soc.org/show_bug.cgi?id=574> Saturating description.
Table of contents
Where the integer regfile in standard scalar
OpenPOWER v3.0B/v3.1B is r0 to r31, SV extends this as r0 to r127.
Likewise FP registers are extended to 128 (fp0 to fp127), and CRs are
-extended to 64 entries, CR0 thru CR63.
+extended to 128 entries, CR0 thru CR127.
The names of the registers therefore reflects a simple linear extension
of the OpenPOWER v3.0B / v3.1B register naming, and in hardware this
Note that ffirst and reduce modes are not anticipated to be high-performance in some implementations. ffirst due to interactions with VL, and reduce due to it requiring additional operations to produce a result. normal, saturate and pred-result are however inter-element independent and may easily be parallelised to give high performance, regardless of the value of VL.
-The Mode table is laid out as follows:
+The Mode table for operations except LD/ST is laid out as follows:
| 0-1 | 2 | 3 4 | description |
| --- | --- |---------|-------------------------- |
## LD/ST ffirst
-ffirst LD/ST to multiple pages via a Vectorised base is considered a security risk due to the abuse of probing multiple pages in rapid succession and getting feedback on which pages would fail. Therefore in these special circumstances requesting ffirst eith a vector base is instead interpreted as element-strided LD/ST. See <https://bugs.libre-soc.org/show_bug.cgi?id=561>
+ffirst LD/ST to multiple pages via a Vectorised base is considered a security risk due to the abuse of probing multiple pages in rapid succession and getting feedback on which pages would fail. Therefore in these special circumstances requesting ffirst with a vector base is instead interpreted as element-strided LD/ST. See <https://bugs.libre-soc.org/show_bug.cgi?id=561>
+and [[sv/ldst]]
# ELWIDTH Encoding
| Value | Mnemonic | Description |
|-------|----------------|------------------------------------|
| 00 | DEFAULT | default behaviour for operation |
-| 01 | `ELWIDTH=b` | Byte: 8-bit integer |
+| 01 | `ELWIDTH=w` | Word: 32-bit integer |
| 10 | `ELWIDTH=h` | Halfword: 16-bit integer |
-| 11 | `ELWIDTH=w` | Word: 32-bit integer |
+| 11 | `ELWIDTH=b` | Byte: 8-bit integer |
+
+This encoding is chosen such that the byte width may be computed as `(3-ew)<<8`
## Elwidth for FP Registers:
| Value | Mnemonic | Description |
|-------|----------------|------------------------------------|
| 00 | DEFAULT | default behaviour for FP operation |
-| 01 | `ELWIDTH=bf16` | Reserved for `bf16` |
+| 01 | `ELWIDTH=f32` | 32-bit IEEE 754 Single floating-point |
| 10 | `ELWIDTH=f16` | 16-bit IEEE 754 Half floating-point |
-| 11 | `ELWIDTH=f32` | 32-bit IEEE 754 Single floating-point |
+| 11 | `ELWIDTH=bf16` | Reserved for `bf16` |
Note:
[`bf16`](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
TODO, important, particularly for crops, mfcr and mtcr, what elwidth
even means. instead it may be possible to use the bits as extra indices
-(add to EXTRA2/3) to access the full 64 CRs at the bit level. TBD, several ideas
+(add to EXTRA2/3) to access the full 128 CRs at the bit level. TBD, several ideas
The actual width of the CRs cannot be altered: they are 4 bit. Also,
for Rc=1 operations that produce a result (in RT or FRT) and corresponding CR, it is
| 110 | R30 | `R30 & (1 << i)` is non-zero |
| 111 | ~R30 | `R30 & (1 << i)` is zero |
+r10 and r30 are at the high end of temporary and unused registers, so as not to interfere with register allocation from ABIs.
+
## CR-based Predication (MASKMODE=1)
When the predicate mode bit is one the 3 bits are interpreted as below.
`offs` is defined as CR32 (4x8) so as to mesh cleanly with Vectorised Rc=1 operations (see below). Rc=1 operations start from CR8 (TBD).
+Notes from Jacob: CR6-7 allows Scalar ops to refer to these without having to do a transfer (v3.0B). Another idea: the DepMatrices treat scalar CRs as one "thing" and treat the Vectors as a completely separate "thing". also: do modulo arithmetic on allocation of CRs.
+
# Extra Remapped Encoding
Shows all instruction-specific fields in the Remapped Encoding `RM[8:18]` for all instruction variants. Note that due to the very tight space, the encoding mode is *not* included in the prefix itself. The mode is "applied", similar to OpenPOWER "Forms" (X-Form, D-Form) on a per-instruction basis, and, like "Forms" are given a designation (below) of the form `RM-nP-nSnD`. The full list of which instructions use which remaps is here [[opcode_regs_deduped]]. (*Machine-readable CSV files have been provided which will make the task of creating SV-aware ISA decoders easier*).
2. Register field numbers (limited typically to 5 bit)
are extended in range, both for Scalar and Vector.
+The register files are therefore extended:
+
+* INT is extended from r0-31 to 128
+* FP is extended from fp0-32 to 128
+* CR is extended from CR0-7 to CR0-127
+
In the following tables register numbers are constructed from the
standard v3.0B / v3.1B 32 bit register field (RA, FRA) and the EXTRA2
or EXTRA3 field from the SV Prefix. The prefixing is arranged so that
else: # scalar
return (spec[0:1] << 5) | RA
+Future versions may extend to 256 by shifting Vector numbering up.
+Scalar will not be altered.
+
## INT/FP EXTRA3
alternative which is understandable and, if EXTRA3 is zero, maps to
were chosen is so that scalar registers in v3.0B and prefixed scalar
registers have access to the same 32 registers.
-| R\*\_EXTRA3 | Mode | Range | MSB downto LSB |
+Fields are as follows:
+
+* Value: R_EXTRA3
+* Mode: register is tagged as scalar or vector
+* Range/Inc: the range of registers accessible from this EXTRA
+ encoding, and the "increment" (accessibility). "/4" means
+ that this EXTRA encoding may only give access (starting point)
+ every 4th register.
+* MSB..LSB: the bit field showing how the register opcode field
+ combines with EXTRA to give (extend) the register number (GPR)
+
+| Value | Mode | Range/Inc | 6..0 |
|-----------|-------|---------------|---------------------|
-| 000 | Scalar | `r0-r31` | `0b00 RA` |
-| 001 | Scalar | `r32-r63` | `0b01 RA` |
-| 010 | Scalar | `r64-r95` | `0b10 RA` |
-| 011 | Scalar | `r96-r127` | `0b11 RA` |
-| 100 | Vector | `r0-r124` | `RA 0b00` |
-| 101 | Vector | `r1-r125` | `RA 0b01` |
-| 110 | Vector | `r2-r126` | `RA 0b10` |
-| 111 | Vector | `r3-r127` | `RA 0b11` |
+| 000 | Scalar | `r0-r31`/1 | `0b00 RA` |
+| 001 | Scalar | `r32-r63`/1 | `0b01 RA` |
+| 010 | Scalar | `r64-r95`/1 | `0b10 RA` |
+| 011 | Scalar | `r96-r127`/1 | `0b11 RA` |
+| 100 | Vector | `r0-r124`/4 | `RA 0b00` |
+| 101 | Vector | `r1-r125`/4 | `RA 0b01` |
+| 110 | Vector | `r2-r126`/4 | `RA 0b10` |
+| 111 | Vector | `r3-r127`/4 | `RA 0b11` |
## INT/FP EXTRA2
alternative which is understandable and, if EXTRA2 is zero will map to
"no effect" i.e Scalar OpenPOWER register naming:
-| R\*\_EXTRA2 | Mode | Range | MSB down to LSB |
-|-----------|-------|---------------|---------------------|
-| 00 | Scalar | `r0-r31` | `0b00 RA` |
-| 01 | Scalar | `r32-r63` | `0b01 RA` |
-| 10 | Vector | `r0-r124` | `RA 0b00` |
-| 11 | Vector | `r2-r126` | `RA 0b10` |
+| Value | Mode | Range/inc | 6..0 |
+|-----------|-------|---------------|-----------|
+| 00 | Scalar | `r0-r31`/1 | `0b00 RA` |
+| 01 | Scalar | `r32-r63`/1 | `0b01 RA` |
+| 10 | Vector | `r0-r124`/4 | `RA 0b00` |
+| 11 | Vector | `r2-r126`/4 | `RA 0b10` |
## CR EXTRA3
-CR encoding is essentially the same but made more complex due to CRs being bit-based. See separate section for explanation and pseudocode.
+CR encoding is essentially the same but made more complex due to CRs being bit-based. See [[svp64/appendix]] for explanation and pseudocode.
Encoding shown MSB down to LSB
-| R\*\_EXTRA3 | Mode | 7..5 | 4..2 | 1..0 |
-|-------------|------|---------| --------|---------|
-| 000 | Scalar | 0b000 | BA[4:2] | BA[1:0] |
-| 001 | Scalar | 0b001 | BA[4:2] | BA[1:0] |
-| 010 | Scalar | 0b010 | BA[4:2] | BA[1:0] |
-| 011 | Scalar | 0b011 | BA[4:2] | BA[1:0] |
-| 100 | Vector | BA[4:2] | 0b000 | BA[1:0] |
-| 101 | Vector | BA[4:2] | 0b010 | BA[1:0] |
-| 110 | Vector | BA[4:2] | 0b100 | BA[1:0] |
-| 111 | Vector | BA[4:2] | 0b110 | BA[1:0] |
+| Value | Mode | Range/Inc | 8..5 | 4..2 | 1..0 |
+|-------|------|---------------|-----------| --------|---------|
+| 000 | Scalar | `CR0-CR7`/1 | 0b0000 | BA[4:2] | BA[1:0] |
+| 001 | Scalar | `CR8-CR15`/1 | 0b0001 | BA[4:2] | BA[1:0] |
+| 010 | Scalar | `CR16-CR23`/1 | 0b0010 | BA[4:2] | BA[1:0] |
+| 011 | Scalar | `CR24-CR31`/1 | 0b0011 | BA[4:2] | BA[1:0] |
+| 100 | Vector | `CR0-CR112`/16 | BA[4:2] 0 | 0b000 | BA[1:0] |
+| 101 | Vector | `CR4-CR116`/16 | BA[4:2] 0 | 0b100 | BA[1:0] |
+| 110 | Vector | `CR8-CR120`/16 | BA[4:2] 1 | 0b000 | BA[1:0] |
+| 111 | Vector | `CR12-CR124`/16 | BA[4:2] 1 | 0b100 | BA[1:0] |
## CR EXTRA2
Encoding shown MSB down to LSB
-| R\*\_EXTRA2 | Mode | 7..5 | 4..2 | 1..0 |
-|-------------|--------|---------|---------|---------|
-| 00 | Scalar | 0b000 | BA[4:2] | BA[1:0] |
-| 01 | Scalar | 0b001 | BA[4:2] | BA[1:0] |
-| 10 | Vector | BA[4:2] | 0b000 | BA[1:0] |
-| 11 | Vector | BA[4:2] | 0b100 | BA[1:0] |
+| Value | Mode | Range/Inc | 8..5 | 4..2 | 1..0 |
+|-------|--------|----------------|---------|---------|---------|
+| 00 | Scalar | `CR0-CR7`/1 | 0b0000 | BA[4:2] | BA[1:0] |
+| 01 | Scalar | `CR8-CR15`/1 | 0b0001 | BA[4:2] | BA[1:0] |
+| 10 | Vector | `CR0-CR112`/16 | BA[4:2] 0 | 0b000 | BA[1:0] |
+| 11 | Vector | `CR8-CR120`/16 | BA[4:2] 1 | 0b000 | BA[1:0] |
# Appendix
projects / libreriscv.git / blobdiff