# EXTRA Field Mapping
+The purpose of the 9-bit EXTRA field mapping is to mark individual
+registers (RT, RA, BFA) as either scalat or vector, and to extend
+their numbering from 0..31 in Power ISA v3.0 to 0..127 in SVP64.
+Three of the 9 bits may also be used up for a 2nd Predicate (Twin
+Predication) leaving a mere 6 bits for qualifying registers. As can
+be seen there is significant pressure on these (and all) SVP64 bits.
+
In Power ISA v3.1 prefixing there are bits which describe and classify
the prefix in a fashion that is independent of the suffix. MLSS for
example. For SVP64 there is insufficient space to make the SVP64 Prefix
EXTRA3 designation. Four or more is given an EXTRA2 designation because
there are only 9 bits available.
-Thirdly, a packing format was decided: for 2R-1W an EXTRA3 indexing
+Thirdly, the instruction was analysed to see if Twin or Single
+Predication was suitable. As a general rule this was if there
+was only a single operand and a single result (`extw` and LD/ST)
+however it was found that some 2 or 3 operand instructions also
+qualify. Given that 3 of the 9 bits of EXTRA had to be sacrificed for use
+in Twin Predication, some compromises were made, here. LDST is
+Twin but also has 3 operands in some operations, so only EXTRA2 can be used.
+
+Fourthly, a packing format was decided: for 2R-1W an EXTRA3 indexing
could have been decided
that RA would be indexed 0 (EXTRA bits 0-2), RB indexed 1 (EXTRA bits 3-5)
-and RT indexed 2 (EXTRA bits 6-8).
+and RT indexed 2 (EXTRA bits 6-8). In some cases (LD/ST with update)
+RA-as-a-source is given a **different** EXTRA index from RA-as-a-result
+(because it is possible to do, and perceived to be useful). Rc=1
+co-results (CR0, CR1) are always given the same EXTRA index as their
+main result (RT, FRT).
+
+Fifthly, in an automated process the results of the analysis
+were outputted in CSV Format for use in machine-readable form
+by sv_analysis.py <https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_analysis.py;hb=HEAD>
+
+This process was laborious but logical, and, crucially, once a
+decision is made (and ratified) cannot be reversed.
+Qualifying future Power ISA Scalar instructions for SVP64
+is **strongly** advised to utilise this same process and the same
+sv_analysis.py program as a canonical method of maintaining the
+relationships. Alterations to that same program which
+change the Designation is **prohibited** once finalised (ratified
+through the Power ISA WG Process). It would
+be similar to deciding that `add` should be changed from X-Form
+to D-Form.
# Single Predication
`llvm.masked.compressstore.*`
followed by
`llvm.masked.expandload.*`
+with a single instruction.
+
+This extreme power and flexibility comes down to the fact that SVP64
+is not actually a Vector ISA: it is a loop-abstraction-concept that
+is applied *in general* to Scalar operations, just like the x86
+`REP` instruction (if put on steroids).
# Reduce modes
Looping which would terminate if the destination was marked as a Scalar.
Scalar Reduction by contrast *keeps issuing Vector Element Operations*
even though the destination register is marked as scalar.
-Thus it is up to the programmer to be aware of this and observe some
-conventions.
+Thus it is up to the programmer to be aware of this, observe some
+conventions, and thus end up achieving the desired outcome of scalar
+reduction.
It is also important to appreciate that there is no
actual imposition or restriction on how this mode is utilised: there
of different offsets masks and values to be inserted has multiple
applications including Video, cryptography and JIT compilation.
+Due to the Deterministic Scheduling,
Subtract and Divide are still permitted to be executed in this mode,
although from an algorithmic perspective it is strongly discouraged.
It would be better to use addition followed by one final subtract,
* Data-driven (CR-driven) fail-on-first activates when Rc=1 or other
CR-creating operation produces a result (including cmp). Similar to
branch, an analysis of the CR is performed and if the test fails, the
- vector operation terminates and discards all element operations at and
- above the current one, and VL is truncated to either
+ vector operation terminates and discards all element operations
+ above the current one (and the current one if VLi is not set),
+ and VL is truncated to either
the *previous* element or the current one, depending on whether
VLi (VL "inclusive") is set.
# Proposed Parallel-reduction algorithm
+**This algorithm contains a MV operation and may NOT be used. Removal
+of the MV operation may be achieved by using index-redirection as was
+achieved in DCT and FFT REMAP**
+
```
/// reference implementation of proposed SimpleV reduction semantics.
///
if pred[i] && other_pred
vec[i] += vec[other];
else if other_pred
- vec[i] = vec[other];
+ XXX VIOLATION OF SVP64 DESIGN XXX
+ XXX vec[i] = vec[other]; XXX
+ XXX VIOLATION OF SVP64 DESIGN XXX
pred[i] |= other_pred;
```
projects / libreriscv.git / blobdiff