From: lkcl <lkcl@web>
Date: Sat, 17 Sep 2022 22:06:09 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~383
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ff2bebbb188db0a82d3c2228669ed87040921e7c;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 56f3cc02c..04d015f5b 100644
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -653,6 +653,9 @@ The issues of allocation for bitmanip etc. from Libre-SOC is therefore
 overwhelmingly made moot. The only downside is that there is no
 `SVP64-Reserved` which will have to be achieved with SPRs (PCR or MSR).
 
+*Most importantly what this scheme does not do is provide large areas
+for other (non-Vectoriseable) RFCs.*
+
 # Potential Opcode allocation solution (2)
 
 One of the risks of the bit 6/7 scheme above is that there is no
@@ -734,8 +737,13 @@ Bit-allocation Summary:
 * Simple-V EXT2nn is restricted to range EXT248-263
 * non-Simple-V EXT2nn (if ever allocated by a future RFC) is restricted to range EXT200-247
 * Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
-* The clear separation between Simple-V and non-Simple-V stops
-  conflict in future RFCs.
+
+The clear separation between Simple-V and non-Simple-V stops
+conflict in future RFCs, both of which get plenty of space.
+EXT000-063 pressure is reduced in both Vectoriseable and
+non-Vectoriseable, and the 100+ Vectoriseable Scalar operations
+identified by Libre-SOC may safely be proposed and each evaluated
+on their merits.
 
 \newpage{}