Example demonstration instruction modified to SVP64 (badly)

Background: https://bugs.libre-soc.org/show_bug.cgi?id=1056#c12

Although split-fields are used in PO1-Prefixing, and it is reasonable to expect to clarify "in-situ" the behaviour of {MLS:D-form} instructions as opposed to {D-Form} instructions, there are reasons why doing the same for PO9-Prefixed SV instructions is neither safe nor sensible. These are illustrated through a hypothetically-proposed extension to addi / paddi (Public v3.1 I 3.3.9 p76).

• Firstly in SV, it is prohibited from adding new operands. addi RT,RA,SI may only be extended to sv.addi RT,RA,SI.
• Secondly, the field positions and bits are also prohibited from being changed merely because of a PO9-Prefix.
• Thirdly, just because of the PO9-Prefix it is prohibited to put an entirely different instruction into the Suffix position. If {PO14} as a 32-bit instruction is defined as "addi", then it is required that {PO9}-{PO14} be a Vectorized "addi", not a Vectorized multiply.
• Fourthly, where PO1-Prefixing of operand fields (often resulting in "split field" redefinitions such as si0||si1) is an arbitrary manually-hand-crafted procedure, SV's entire PO9-Prefixing of Register Fields is fully-automated i.e. RISC-paradigm uniform and regular.
• Fifthly, the "unclean" exposure of SV concepts directly into the RTL creates a massive "unreadability" problem. you can't actually find the "add" in amongst all the "operand cruft", and Saturation, Sub-Vectors, Element-width Overrides, Predication, REMAP, all have not been introduced yet!

Add Immediate D-Form

• addi RT,RA,SI

    DWI:
        |    14 |   RT            |    RA       |     SI       |
        | 0     | 6               | 11          | 16        31 |

Prefixed Add Immediate MLS:D-form

• paddi RT,RA,SI,R

    Prefix:
        |    1  |   2    | 0 | // | R  | //  |     si0         |
        | 0     | 6      | 8 | 9  | 11 | 12  | 14           31 |

    Suffix::
        |    14 |   RT            |    RA       | si1          |
        | 0     | 6               | 11          | 16        31 |

Vectorized Add Immediate SVRM-Normal:D-form

• sv.addi RT,RA,SI

    Prefix:
        |    9  |  ..    |     Stuff | EXTRA    | MODEBITS     |
        | 0     | 6      | 8         | 17    26 | 27        31 |
    Suffix:
        |    14 |   RT            |    RA       |     SI       |
        | 0     | 6               | 11          | 16        31 |

Pseudo-code:

    if "addi" then
        RT <- (RA|0) + EXTS64(SI)
    if "paddi" & R=0 then
        RT <- (RA|0) + EXTS64(si0||si1)
    if "paddi" & R=1 then
        RT <- CIA + EXTS64(si0||si1)
    if "sv.addi" then # beginning of spec writer nightmare
        # spec writer's worst nightmare unfolds here
        svra <- DECODE_WITH_EXTRA3(Suffix.D-Form.RA, EXTRA[0:2])
        svrt <- DECODE_WITH_EXTRA3(Suffix.D-Form.RT, EXTRA[3:5])
        svsi <- Suffix.D-Form.SI
        # finally got to the actual add which is exactly the same as "addi"
        # but we still have to elements and elwidth overrides *and* REMAP
        # *and* predication and god knows what else, none of which is at
        # all appropriate to put *here*.  this *should* just be like "addi":
        #      svrt <- (svra|0) + EXTS64(SI)
        src <- ELEMENT_FROM_GPR(svra|0, SVSTATE.srcstep, REMAP, Prefix.ELWIDTH)
        result <- src + EXTS64(svsi)
        ELEMENT_OF_GPR(svrt, SVSTATE.dststep, REMAP, Prefix.ELWIDTH) <- result

Special Registers Altered:

None