(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 56f3cc02c50c402df2869ce8c6e89b0b08b34661..04d015f5b697073c0d5001214b711c7f2b04963f 100644 (file)
--- 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{}