(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 72458c425b97828ca4c4c38be24253d7e7e6c122..fb77529d69b10ee5ae575c872150b402676c6827 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -1,5 +1,7 @@
 # The Rules
 
+[[!toc]]
+
 SVP64 is designed around these fundamental and inviolate principles:
 
 1. There are no actual Vector instructions: Scalar instructions
@@ -89,4 +91,24 @@ overwrites LR.
 
 Well over 500 Vectorised branch instructions exist in SVP64 due to the
 number of options available: close integration and interaction with
-the base Scalar Branch was unavoidable.
+the base Scalar Branch was unavoidable in order to create Conditional
+Branching suitable for parallel 3D / CUDA GPU workloads.
+
+# Saturation
+
+The application of Saturation as a retro-fit to a Scalar ISA is challenging.
+It does help that within the SFFS Compliancy subset there are no Saturated
+operations at all: only in VSX.
+
+Saturation does not inherently change the instruction itself: it does however
+come with some fundamental implications, when applied. For example:
+a Floating-Point operation that would normally raise an exception will
+no longer do so, instead setting the CR1.SO Flag.  Another quirky
+example: signed operations which produce a negative result will be
+truncated to zero if Unsigned Saturation is requested.
+
+One very important aspect for implementors is that the operation in
+effect has to be considered to be performed at infinite precision,
+followed by saturation detection. In practice this does not actually
+require infinite precision hardware! Two 8-bit integers being
+added can only ever overflow into a 9-bit result.