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