From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Thu, 25 May 2023 13:42:49 +0000 (+0100)
Subject: clarify hypothetical sv.addi+addi+paddi in spec
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6759db39e11dd1809a4610bd6192b2fbd0a36853;p=libreriscv.git

clarify hypothetical sv.addi+addi+paddi in spec
---

diff --git a/openpower/sv/ls010/hypothetical_addi.mdwn b/openpower/sv/ls010/hypothetical_addi.mdwn
index f2f59320b..429f899d1 100644
--- a/openpower/sv/ls010/hypothetical_addi.mdwn
+++ b/openpower/sv/ls010/hypothetical_addi.mdwn
@@ -1,5 +1,9 @@
 # Example demonstration instruction modified to SVP64 (badly)
 
+<!-- hide -->
+Background: <https://bugs.libre-soc.org/show_bug.cgi?id=1056#c12>
+<!-- show -->
+
 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
@@ -11,6 +15,22 @@ extension to `addi` / `paddi` (Public v3.1 I 3.3.9 p76).
   `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 Vectorised "addi",
+  **not** a Vectorised 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
 
@@ -64,7 +84,13 @@ Pseudo-code:
         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"
-        GPR(svrt) <- (svra|0) + EXTS64(svsi)
+        # 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: