(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 377cfd3b5db6e04249f432995da3a5e92faf370d..3d1eff2994f9ffcd6a060077d40116b8c4fcbb4f 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -80,21 +80,22 @@ to be reserved.
 
 # Binary Interoperability
 
-Power ISA is long-term stable. A catastrophic mistake has been made in
-ARM SVE/2 and RISC-V RVV: "Silicon-Partner" Scalability, marketed as
-a feature, allows the same instructions to mean different things on
-different implementations (a different Vector bitwidth).
-Binary interoperability is thus not only impossible to achieve but
-Illegal Instruction trap-and-emulate is also out of the question.
-Worse than that a **future** vendor may suddenly render
-**all existing** hardware non-interoperable, which is the worst possible
-thing for any specification to permit
-yet this is what SVE and RVV do *by design*.
-
+Power ISA has a reputation as being long-term stable.
 **Simple-V guarantees binary interoperability** by defining fixed
-register file bitwidths and size for all instructions.  This does
+register file bitwidths and size for all instructions.
+The seduction of permitting different implementors to choose a register file
+bitwidth and size with the same instructions unfortunately has
+the catastrophic side-effect of introducing not only binary incompatibility
+but silent data corruption as well as no means to trap-and-emulate differing
+bitwidths.[^vsx256]
+
+Thus "Silicon-Partner" Scalability
+is prohibited in the Simple-V Scalable Vector ISA,
+This does
 mean that `RESERVED` space is crucial to have, in order
-to safely provide future expanded register file bitwidths and sizes.[^msr]
+to safely provide future expanded register file bitwidths and sizes[^msr]
+**at the discretion of and with the full authority of the OPF ISA WG**,
+not the implementor ("Silicon Partner").
 
 # Hardware Implementations
 
@@ -674,3 +675,4 @@ operations.
 [^only2]: reminder that this proposal only needs 75% of two POs for Scalar instructions. The rest of EXT200-263 is for general use.
 [^ext001]: Recall that EXT100 to EXT163 is for Public v3.1 64-bit-augmented Operations prefixed by EXT001, for which, from Section 1.6.3, bit 6 is set to 1.  This concept is where the above scheme originated. Section 1.6.3 uses the term "defined word" to refer to pre-existing EXT000-EXT063 32-bit instructions so prefixed to create the new numbering EXT100-EXT163, respectively
 [^futurevsx]: A future version or other Stakeholder *may* wish to drop Simple-V onto VSX: this would be a separate RFC
+[^vsx256] imagine a future VSX-256 using the exact same instructions as VSX. it would catstrophically damage existing IBM POWER8,9,10 hardware's reputation and that of Power ISA overall.