(no commit message)

[libreriscv.git] / openpower / sv / svp64 / appendix.mdwn

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index 8b69188b996a31e25594c40db67c156e6362afd0..bfbae889afeda5af7303df75e02b4eb1f416a95c 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -118,6 +118,54 @@ It is important to note that having a different v3.0B Scalar opcode
 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.
@@ -184,8 +232,8 @@ but only if in doing so they preserve Program Order at the Element Level.
 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.