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

---

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index fcb3830a9..17618fef0 100644
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -535,6 +535,11 @@ 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.
+Setting a simple inviolate rule helps avoid this scenario but does
+need to be borne in mind when discussing potential allocation
+schemes, as well as when new Vectoriseable Opcodes are proposed
+for addition by future RFCs: the opcodes **must** be uniformly
+added to Scalar **and** Vector spaces.
 
 \newpage{}
 # Potential Opcode allocation solution