(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 9f487114cd05e8cd3a16da16ed779cbceba7c558..fcb3830a9ce201cf4b8e10168640da0c69024c59 100644 (file)
--- 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