clarify binary-incompatibility paragraph

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index 721e152aac79931b6a53188cb1753eba1d04e939..27d6740da3df18c46c2e902687b1b753caabdeba 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -113,22 +113,22 @@ to be reserved.
 
 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.
+register file bitwidths and size for a given set of 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]
 
-"Silicon-Partner" Scalability is identical to mixing 32-bit Power ISA
-with 64-bit in the same binary (just as catastrophic), and
-is prohibited in the Simple-V Scalable Vector ISA,
-`RESERVED` space is thus crucial to have, in order
-to provide the option of
-future expanded register file bitwidths and sizes[^msr],
-under **explicitly-distinguishable** encoding,
-**at the discretion of the OPF ISA WG**,
-not the implementor ("Silicon Partner").
+"Silicon-Partner" Scalability is identical to attempting to run 64-bit
+Power ISA binaries without setting - or having `MSR.SF` - on "Scaled"
+32-bit hardware: **the same opcodes** were shared between 32 and 64 bit.
+`RESERVED` space is thus crucial
+to have, in order to provide the **OPF ISA WG** - not implementors
+("Silicon Partners") - with the option to properly review and decide
+any (if any) future expanded register file bitwidths and sizes[^msr],
+**under explicitly-distinguishable encodings** so as to guarantee
+long-term stability and binary interoperability.
 
 # Hardware Implementations