(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index fb77529d69b10ee5ae575c872150b402676c6827..e4473b9ff9ea9b07e19b2e9d995a47265f788eae 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -98,7 +98,7 @@ Branching suitable for parallel 3D / CUDA GPU workloads.
 
 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.
+operations at all: they are only added in VSX.
 
 Saturation does not inherently change the instruction itself: it does however
 come with some fundamental implications, when applied. For example:
@@ -112,3 +112,29 @@ 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.
+
+Overall some care and consideration needs to be applied.
+
+# Fail-First
+
+Fail-First (both the Load/Store and Data-Dependent variants)
+is worthy of a special mention in its own right. Where VL is
+normally forward-looking and may be part of a pre-decode phase
+in a (simplified) pipelined architecture with no Read-after-Write Hazards,
+Fail-First changes that because at any point during the execution
+of the element-level instructions, one of those elements may not only
+terminate further continuation of the hardware-for-looping but also
+effect a change of VL:
+
+```
+for i in range(VL):
+    result = element_operation(GPR(RA+i), GPR(RB+i))
+    if test(result):
+        VL = i
+        break
+```
+
+This is not exactly a violation of SVP64 Rules, more of a breakage
+of user expectations, particularly for LD/ST where exceptions
+would normally be expected to be raised, Fail-First provides for
+avoidance of those exceptions.