(no commit message)

diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn
index 626c3640ab3d20f73437cebcde45925dc0971c00..2d5b639f684a9be479fc2f6496c35e385aec275f 100644 (file)
--- a/openpower/sv/svp64/appendix.mdwn
+++ b/openpower/sv/svp64/appendix.mdwn
@@ -18,8 +18,6 @@ Table of contents:
 
 # Partial Implementations
 
-See [[sv/compliancy_levels]] for full details.
-
 It is perfectly legal to implement subsets of SVP64 as long as illegal
 instruction traps are always raised on unimplemented features,
 so that soft-emulation is possible,
@@ -31,54 +29,7 @@ not implemented including reserved ones for future use must raise an illegal
 instruction trap if read or written. This allows software the
 opportunity to emulate the context created by the given SPR.
 
-**Embedded Scalar Scenario**
-
-In this scenario an implementation does not wish to implement the Vectorisation
-but simply wishes to take advantage of predication or other feature
-of SVP64, such as instructions that might only be available if prefixed.
-Such an implementation would be entirely free to do so with the proviso
-that:
-
-* any attempts to call `setvl` shall either raise an illegal instruction
-  or be partially implemented to set SVSTATE correctly.
-* if SVSTATE contains any value in any bit that is not supported
-  in hardware, an illegal instruction shall be raised when an SVP64
-  prefixed instruction is executed.
-* if SVSTATE contains values requesting supported features at the time
-  that the prefixed instruction is executed then it is executed in
-  hardware as per specification, with no illegal exception trap raised.
-
-Example, assuming that hardware implements scalar operations only,
-and implements predication but not elwidth overrides:
-
-    setvli r0, 4            # sets VL equal to 4
-    sv.addi r5, r0, 1       # raises an 0x700 trap
-    setvli r0, 1            # sets VL equal to 1
-    sv.addi r5, r0, 1       # gets executed by hardware
-    sv.addi/ew=8 r5, r0, 1  # raises an 0x700 trap
-    sv.ori/sm=EQ r5, r0, 1  # executed by hardware
-
-The first `sv.addi` raises an illegal instruction trap because
-VL has been set to 4, and this is not supported.  Likewise
-elwidth overrides if requested always raise illegal instruction
-traps.
-
-**Full implementation (current revision) scenario**
-
-In this scenario, SVP64 is implemented as it stands in its entirety.
-However a future revision or a competitor processor decides to also
-implement portions of Quad-Precision VSX as SVP64-Vectorised.
-Compatibility is **only** achieved if the earlier implementor raises
-illegal instruction exceptions on **all** unimplemented opcodes within
-the SVP64-Prefixed space, *even those marked by the Scalar Power ISA as
-not needing to raise illegal instructions*.
-
-Additionally a future version of the specification adds a new feature,
-requiring an additional SPR.  This SPR was, at the time of implementation,
-marked as "Reserved". The early implementation raises an illegal
-instruction trap when this SPR is read or written, and consequently has
-an opportunity to trap-and-emulate the full capability of the revised
-version of the SVP64 Specification.
+See [[sv/compliancy_levels]] for full details.
 
 # XER, SO and other global flags
 
@@ -126,7 +77,8 @@ It can clearly be seen that the carry chains from one
 256-bit "Big Integer Add" has been performed, and that
 CA contains the 257th bit.  A one-instruction 512-bit Add
 may be performed by setting VL=8, and a one-instruction
-1024-bit add by setting VL=16, and so on.
+1024-bit add by setting VL=16, and so on.  More on
+this in [[openpower/sv/biginteger]]
 
 # v3.0B/v3.1 relevant instructions