From 12ba845e5e5a2d0ba83394f530a8a6eb3e08fde9 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 16 Sep 2022 09:55:14 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls001.mdwn | 5 +++++ 1 file changed, 5 insertions(+) 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 -- 2.30.2