that is different from an SVP64 one is highly undesirable: the complexity
in the decoder is greatly increased.
+# EXTRA Field Mapping
+
+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
+"self-describing", and consequently every single Scalar instruction
+had to be individually analysed, by rote, to craft an EXTRA Field Mapping.
+This process was semi-automated and is described in this section.
+The final results, which are part of the SVP64 Specification, are here:
+
+* [[openpower/opcode_regs_deduped]]
+
+Firstly, every instruction's mnemonic (`add RT, RA, RB`) was analysed
+from reading the markdown formatted version of the Scalar pseudocode
+which is machine-readable and found in [[openpower/isatables]]. The
+analysis gives, by instruction, a "Register Profile". `add RT, RA, RB`
+for example is given a designation `RM-2R-1W` because it requires
+two GPR reads and one GPR write.
+
+Secondly, the total number of registers was added up (2R-1W is 3 registers)
+and if less than or equal to three then that instruction could be given an
+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
+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). 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).
+
+Fourthly, 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 some 2 or 3 operand instructions also qualify.
+
+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>
+
+Quslifying future Power ISA Scalar instructions for SVP64
+is **strongly** advised to utilise this same process and the same
+sv_analysis.py program. 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
This is a standard mode normally found in Vector ISAs. every element in every source Vector and in the destination uses the same bit of one single predicate mask.
Opportunities where this is possible include an `OR` operation
or a MIN/MAX operation: it may be possible to parallelise the reduction,
but for Floating Point it is not permitted due to different results
-being obtained if the reduction is not executed in strict sequential
-order.
+being obtained if the reduction is not executed in strict Program-Sequential
+Order.
In essence it becomes the programmer's responsibility to leverage the
pre-determined schedules to desired effect.
-## Scalar result reduce mode
+## Scalar result reduction and iteration
Scalar Reduction per se does not exist, instead is implemented in SVP64
as a simple and natural relaxation of the usual restriction on the Vector
provided.
In this mode, which is suited to operations involving carry or overflow,
-one register must be identified by the programmer as being the "accumulator".
-Scalar reduction is thus categorised by:
+one register must be assigned, by convention by the programmer to be the
+"accumulator". Scalar reduction is thus categorised by:
* One of the sources is a Vector
* the destination is a scalar
also the scalar destination (which may be informally termed
the "accumulator")
* That the source register type is the same as the destination register
- type identified as the "accumulator". scalar reduction on `cmp`,
+ type identified as the "accumulator". Scalar reduction on `cmp`,
`setb` or `isel` makes no sense for example because of the mixture
between CRs and GPRs.
for i in range(VL):
iregs[RA] += iregs[RB+i] # RT==RA
-However, *unless* the operation is marked as "mapreduce", SV ordinarily
+However, *unless* the operation is marked as "mapreduce" (`sv.add/mr`)
+SV ordinarily
**terminates** at the first scalar operation. Only by marking the
operation as "mapreduce" will it continue to issue multiple sub-looped
(element) instructions in `Program Order`.
# Fail-on-first
-Data-dependent fail-on-first has two distinct variants: one for LD/ST,
-the other for arithmetic operations (actually, CR-driven). Note in each
+Data-dependent fail-on-first has two distinct variants: one for LD/ST
+(see [[sv/ldst]],
+the other for arithmetic operations (actually, CR-driven)
+([[sv/normal]]) and CR operations ([[sv/cr_ops]]).
+Note in each
case the assumption is that vector elements are required appear to be
executed in sequential Program Order, element 0 being the first.
Numbering relationships for CR fields are already complex due to being
in BE format (*the relationship is not clearly explained in the v3.0B
-or v3.1B specification*). However with some care and consideration
+or v3.1 specification*). However with some care and consideration
the exact same mapping used for INT and FP regfiles may be applied,
just to the upper bits, as explained below. The notation
`CR{field number}` is used to indicate access to a particular
which accesses one bit of the 32 bit Power ISA v3.0B
Condition Register)
+`CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:
+
+ CR{7-n} = CR[32+n*4:35+n*4]
+
+For SVP64 the relationship for the sequential
+numbering of elements is to the CR **fields** within
+the CR Register, not to individual bits within the CR register.
+
In OpenPOWER v3.0/1, BF/BT/BA/BB are all 5 bits. The top 3 bits (0:2)
select one of the 8 CRs; the bottom 2 bits (3:4) select one of 4 bits
*in* that CR. The numbering was determined (after 4 months of
CR element*. Greatly simplified pseudocode:
for i in range(VL):
- # calculate the vector result of an add iregs[RT+i] = iregs[RA+i]
- + iregs[RB+i] # now calculate CR bits CRs{8+i}.eq = iregs[RT+i]
- == 0 CRs{8+i}.gt = iregs[RT+i] > 0 ... etc
+ # calculate the vector result of an add
+ iregs[RT+i] = iregs[RA+i] + iregs[RB+i]
+ # now calculate CR bits
+ CRs{8+i}.eq = iregs[RT+i] == 0
+ CRs{8+i}.gt = iregs[RT+i] > 0
+ ... etc
If a "cumulated" CR based analysis of results is desired (a la VSX CR6)
then a followup instruction must be performed, setting "reduce" mode on
/// `temp_pred` is a user-visible Vector Condition register
///
/// all input arrays have length `vl`
-def reduce( vl, vec, pred, pred,):
+def reduce(vl, vec, pred):
step = 1;
while step < vl
step *= 2;
else if other_pred
vec[i] = vec[other];
pred[i] |= other_pred;
+```
+we'd want to use something based on the above pseudo-code
+rather than the below pseudo-code -- reasoning here:
+<https://bugs.libre-soc.org/show_bug.cgi?id=697#c11>
+
+```
def reduce( vl, vec, pred, pred,):
j = 0
vi = [] # array of lookup indices to skip nonpredicated
projects / libreriscv.git / blobdiff