fields set to a reserved value must cause an illegal instruction trap,
to allow emulation of future instruction sets.
-This is unlike OpenPower ISA v3.1, which in many instances does not require a trap.
+This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero.
# Identity Behaviour
-SVP64 is designed so that when the prefix is all zeros, no effect or
+SVP64 is designed so that when the prefix is all zeros, and
+ VL=1, no effect or
influence occurs (no augmentation) such that all standard OpenPOWER
v3.0/1B instructions covered by the prefix are "unaltered". This is termed `scalar identity behaviour` (based on the mathematical definition for "identity", as in, "identity matrix" or better "identity transformation").
-Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops`, whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity operation").
+Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix)
+ whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity operation").
-# Register Naming
+# XER, SO and other global flags
+
+Vector systems are expected to be high performance. This is achieved
+through parallelism, which requires that elements in the vector be
+independent. XER SO and other global "accumulation" flags (CR.OV) cause
+Read-Write Hazards on single-bit global resources, having a significant
+detrimental adverse effect.
+
+Consequently in SV, XER.SO and CR.OV behaviour is disregarded. XER is
+simply neither read nor written. This includes when `scalar identity behaviour` occurs. If OpenPOWER v3.0/1 scalar behaviour is desired then OpenPOWER v3.0/1 instructions should be used, not SV Prefixed ones.
+
+An interesting side-effect of this decision is that the OE flag is now free for other uses when SV Prefixing is used.
+
+# Additional instructions: v3.0B/v3.1B overrides
+
+SV is primarily designed for use as an efficient hybrid 3D GPU / VPU / CPU ISA.
+
+As mentioned above, OE=1 is not applicable in SV, freeing this bit for alternative uses. Additionally, Vectorisation of the VSX SIMD system likewise makes no sense whatsoever: SV replaces VSX and provides, at the very minimum, predication (which VSX was not designed to incorporate). Thus all VSX Major Opcodes - all of them - are "unused" and raise illegal instruction exceptions in SV Prefix Mode.
+
+This leaves several Major Opcodes free for use by SV to fit alternative instructions: Vector Product, Vector Normalise, [[sv/mv.swizzle]], Texture LD/ST operations, and others critical to an efficient, effective 3D GPU and VPU ISA, and included as standard in other commercially-successful GPU ISAs.
+
+# Register Naming and size
SV Registers are simply the INT, FP and CR register files extended
linearly to larger sizes; SV Vectorisation iterates sequentially through these registers.
Where the integer regfile in standard scalar
-OpenPOWER v3.0B and v3.1B is r0 to r31, SV extends this as r0 to r127.
+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.
RB etc. are interpreted and treated as v3.0B / v3.1B scalar registers. This is part of
`scalar identity behaviour` described above.
+## Future expansion.
+
+With the way that EXTRA fields are defined and applied to register fields,
+future versions of SV may involve 256 or greater registers. To accommodate 256 registers, numbering of Vectors will simply shift up by one bit, without
+requiring additional prefix bits. Backwards binary compatibility may be achieved with a PCR bit (Program Compatibility Register). Beyond this, further discussion is out of scope for this version of svp64.
+
# Remapped Encoding (`RM[0:23]`)
To allow relatively easy remapping of which portions of the Prefix Opcode
| MASK | `1:3` | Execution Mask |
| ELWIDTH | `4:5` | Element Width |
| SUBVL | `6:7` | Sub-vector length |
-| Rdest\_EXTRA3 | `8:10` | extends Rdest (Uses R\*\_EXTRA3 Encoding) |
-| Rsrc1\_EXTRA3 | `11:13` | extends Rsrc1 (Uses R\*\_EXTRA3 Encoding) |
-| Rsrc2\_EXTRA3 | `14:16` | extends Rsrc3 (Uses R\*\_EXTRA3 Encoding) |
+| Rdest\_EXTRA3 | `8:10` | extends Rdest |
+| Rsrc1\_EXTRA3 | `11:13` | extends Rsrc1 |
+| Rsrc2\_EXTRA3 | `14:16` | extends Rsrc3 |
+| ELWIDTH_SRC | `17:18` | Element Width for Source |
| MODE | `19:23` | changes Vector behaviour |
These are for 2 operand 1 dest instructions, such as `add RT, RA,
-RB`. However also included are unusual instructions with the same src
-and dest, such as `rlwinmi`.
+RB`. However also included are unusual instructions with an implicit dest
+that is identical to its src reg, such as `rlwinmi`.
-Normally, with instructions such as `rlwinmi`, the scalar v3.0B ISA would not have sufficient bits to allow
+Normally, with instructions such as `rlwinmi`, the scalar v3.0B ISA would not have sufficient bit fields to allow
an alternative destination. With SV however this becomes possible.
Therefore, the fact that the dest is implicitly also a src should not
mislead: due to the *prefix* they are different SV regs.
each may be *independently* made vector or scalar, and be independently
augmented to 7 bits in length.
+Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing.
+
## RM-2P-1S1D
| Field Name | Field bits | Description |
| ELWIDTH_SRC | `17:18` | Element Width for Source |
| MODE | `19:23` | changes Vector behaviour |
-note in [[discussion]]: TODO, evaluate if 2nd SUBVL should be added.
-conclusion: no. 2nd SUBVL makes no sense except for mv, and that is
-covered by [[mv.vec]]
+Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing.
## RM-2P-2S1D/1S2D
Twin Predication. therefore these are treated as RM-2P-2S1D and the
src spec for RA is also used for the same RA as a dest.
+Note that if ELWIDTH != ELWIDTH_SRC this may result in reduced performance or increased latency in some implementations due to lane-crossing.
# Mode
* **normal** mode is straight vectorisation. no augmentations: the vector comprises an array of independently created results.
* **ffirst** or data-dependent fail-on-first: see separate section. the vector may be truncated depending on certain criteria.
*VL is altered as a result*.
-* **sat mode** or saturation: clamps each elemrnt result to a min/max rather than overflows / wraps. allows signed and unsigned clamping.
+* **sat mode** or saturation: clamps each elemrnt result to a min/max rather than overflows / wraps. allows signed and unsigned clamping.
* **reduce mode**. a mapreduce is performed. the result is a scalar. a result vector however is required, as the upper elements may be used to store intermediary computations. the result of the mapreduce is in the first element with a nonzero predicate bit. see separate section below.
note that there are comprehensive caveats when using this mode.
-* **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch testing) and if the test fails it is as if the predicate bit was zero. When Rc=1 the CR element (CR0) however is still stored in the CR regfile. This scheme does not apply to crops (crand, cror).
+* **pred-result** will test the result (CR testing selects a bit of CR and inverts it, just like branch testing) and if the test fails it is as if the predicate bit was zero. When Rc=1 the CR element however is still stored in the CR regfile, even if the test failed. This scheme does not apply to crops (crand, cror). See appendix for details.
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 independent and may easily be parallelised to give high performance, regardless of the value of VL.
where overlap will occur, *or* that they use the same starting point
but select different *bits* of the same CRs
-`offs` is defined as CR48 (6x8) so as to mesh cleanly with Vectorised Rc=1 operations (see below). Arithmetic Rc=1 operations start from CR16 (TBD); FP Rc=1 from CR32 (TBD).
+`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).
# Appendix
new crweird instruction, transferring the relevant CR bits to a scalar
integer and testing it for nonzero. see [[sv/cr_int_predication]]
+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 dest elwidth.
## Reduce mode
-1. limited to single predicated dual src operations (add RT, RA, RB) and
- to triple source operations where one of the inputs is set to a scalar
- (these are rare)
+1. limited to single predicated dual src operations (add RT, RA, RB).
+ triple source operations are prohibited (fma).
2. limited to operations that make sense. divide is excluded, as is
subtract (X - Y - Z produces different answers depending on the order)
and asymmetric CRops (crandc, crorc). sane operations:
TODO: case where RA!=RB which involves first a vector of 2-operand
results followed by a mapreduce on the intermediates.
-Note that when SUBVL!=1 the sub-elements are *independent*, i.e. they
+Note that when SVM is clear and SUBVL!=1 the sub-elements are *independent*, i.e. they
are mapreduced per *sub-element* as a result. illustration with a vec2:
result.x = op(iregs[RA].x, iregs[RA+1].x)
result.x = op(result.x, iregs[RA+i].x)
result.y = op(result.y, iregs[RA+i].y)
-When SVM is set and SUBVL!=1, another variant is enabled, which switches
-to `RM-2P-2S1D` such that different elwidths may be applied to src
-and dest.
+When SVM is set and SUBVL!=1, another variant is enabled.
for i in range(VL):
result = op(iregs[RA+i].x, iregs[RA+i].x)
vectorised operations are effectively `nops` which is
*precisely the desired and intended behaviour*.
+## pred-result mode
+
+This mode merges common CR testing with predication, saving on instruction count. Below is the pseudocode excluding predicate zeroing and elwidth overrides.
+
+ for i in range(VL):
+ # predication test, skip all masked out elements.
+ if predicate_masked_out(i):
+ continue
+ result = op(iregs[RA+i], iregs[RB+i])
+ CRnew = analyse(result) # calculates eq/lt/gt
+ # Rc=1 always stores the CR
+ if Rc=1:
+ crregs[offs+i] = CRnew
+ # now test CR, similar to branch
+ if CRnew[BO[0:1]] != BO[2]:
+ continue # test failed: cancel store
+ # result optionally stored but CR always is
+ iregs[RT+i] = result
+
+The reason for allowing the CR element to be stored is so that post-analysis
+of the CR Vector may be carried out. For example: Saturation may have occurred (and been prevented from updating, by the test) but it is desirable to know *which* elements fail saturation.
+
+Note that predication is still respected: predicate zeroing is slightly different: elements that fail the CR test *or* are masked out are zero'd.
## CR Operations
When vectorized, the CR inputs/outputs are sequentially read/written
to 4-bit CR fields. Vectorised Integer results, when Rc=1, will begin
-writing to CR16 (TBD evaluate) and increase sequentially from there.
-Vectorised FP results, when Rc=1, start from CR32 (TBD evaluate).
+writing to CR8 (TBD evaluate) and increase sequentially from there.
This is so that:
* implementations may rely on the Vector CRs being aligned to 8. This
(8 CRs per batch), for high performance implementations.
* scalar Rc=1 operation (CR0, CR1) and callee-saved CRs (CR2-4) are not
overwritten by vector Rc=1 operations except for very large VL
-* Vector FP and Integer Rc=1 operations do not overwrite each other
- except for large VL.
-* CR-based predication, from CR48, is also not interfered with
+* CR-based predication, from CR32, is also not interfered with
(except by large VL).
However when the SV result (destination) is marked as a scalar by the
(see [[discussion]]. some alternative schemes are described there)
+### Rc=1 when SUBVL!=1
+
+sub-vectors are effectively a form of SIMD (length 2 to 4). Only 1 bit of predicate is allocated per subvector; likewise only one CR is allocated
+per subvector.
+
+This leaves a conundrum as to how to apply CR computation per subvector, when normally Rc=1 is exclusively applied to scalar elements. A solution is to perform a bitwise OR or AND of the subvector tests. Given that OE is ignored, rhis field may (when available) be used to select OR or AND behavior.
+
### Table of CR fields
CR[i] is the notation used by the OpenPower spec to refer to CR field #i,
projects / libreriscv.git / blobdiff