From ff2bebbb188db0a82d3c2228669ed87040921e7c Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 17 Sep 2022 23:06:09 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls001.mdwn | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) 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{} -- 2.30.2