-
-* [[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, 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). 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
+[[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, 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). 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