From: lkcl <lkcl@web>
Date: Fri, 16 Sep 2022 08:47:50 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~413
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=bd1692037b5426b41e9f01f6e509a283515a9b79;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 9f487114c..fcb3830a9 100644
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -515,6 +515,27 @@ For each of EXT059 and EXT063:
   [under evaluation](https://bugs.libre-soc.org/show_bug.cgi?id=923)
   as of 08Sep2022
 
+# Adding new opcodes.
+
+With Simple-V being a type of Zero-Overhead Loop Engine on top of
+Scalar operations some clear guidelines are needed on how both
+existing "Defined Words" (Public v3.1 Section 1.6.3 term) and future
+Scalar operations are added within the 64-bit space.  Examples of
+legal and illegal allocations are given later.
+
+The primary point is that once an instruction is defined in Scalar
+32-bit form its corresponding space **must** be reserved in the
+SVP64 area with the exact same 32-bit form, even if that instruction
+is "Unvectoriseable" (`sc`, `sync`, `rfid` and `mtspr` for example).
+Instructions may **not** be added in the Vector space without also
+being added in the Scalar space, and vice-versa, *even if Unvectoriseable*.
+
+This is extremely important because the worst possible situation
+is if a conflicting Scalar instruction is added by another Stakeholder,
+which then turns out to be Vectoriseable: it would then have to be
+added to the Vector Space with a *completely different Defined Word*
+and things go rapidly downhill in the Decode Phase from there.
+
 \newpage{}
 # Potential Opcode allocation solution