(no commit message)

diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn
index 567aa1656801259310f1d4b441467b6ef18562e3..1d576b90235fdd440a22e633f8bfa8b279e3672a 100644 (file)
--- a/openpower/sv/svp64.mdwn
+++ b/openpower/sv/svp64.mdwn
@@ -74,7 +74,8 @@ This document focusses specifically on how that fits into available space.  The
 
 For the new fields added in SVP64, instructions that have any of their
 fields set to a reserved value must cause an illegal instruction trap,
-to allow emulation of future instruction sets.  Unless otherwise stated, reserved values are always all zeros.
+to allow emulation of future instruction sets.  This includes SVP64 SPRs.
+Unless otherwise stated, reserved values are always all zeros.
 
 This is unlike OpenPower ISA v3.1, which in many instances does not require a trap if reserved fields are nonzero.  Where the standard OpenPOWER definition
 is intended the red keyword `RESERVED` is used.
@@ -91,6 +92,11 @@ Note that this is completely different from when VL=0.  VL=0 turns all operation
 
 The significance of identity behaviour is that instructions added under svp64 to the 32 bit suffix are not only accessible to svp64: as long as implementors conform to identity behaviour (set the prefix to all zeros) they may use the instructions without needing to actually implement SV itself.
 
+Implementors intending only to implement Scalar operations (identity behaviour only)
+are however required to at least support the SVSTATE
+SPR, which if nonzero (no longer identity behaviour) must cause all SVP64 instructions to raise an illegal instruction trap. This allows full
+soft-implementation of SVP64.
+
 # Register Naming and size
 
 SV Registers are simply the INT, FP and CR register files extended