(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 404dbf564c597fdcac357c0cc4a8a75cc4212e6f..ad3662fe6d74eea96d79bb1efc2ea2f3ed161c94 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -5,7 +5,7 @@ SVP64 is designed around these fundamental and inviolate principles:
 1. There are no actual Vector instructions: Scalar instructions
    are the sole exclusive bedrock.
 2. No scalar instruction ever deviates in its encoding or meaning
-   just because it is prefixed.
+   just because it is prefixed (caveats below)
 3. A hardware-level for-loop makes vector elements 100% synonymous
    with scalar instructions (the suffix)
 
@@ -13,6 +13,14 @@ That said, there are a few exceptional places where these rules get
 bent, and others where the rules take some explaining,
 and this page tracks them.
 
+The modification caveat obviously exempts element width overrides,
+which still do not actually modify the meaning of the instruction:
+an add remains an add, even if it is only an 8-bit add rather than
+a 64-bit add. elwidth overrides *definitely* do not alter the 3.0 encoding.
+Other "modifications" such as saturation or Data-dependent Fail-First
+likewise are post-augmentation or post-analysis, and do not actually
+fundamentally change an add operation into a subtract for example.
+
 *(An experiment was attempted to modify LD-immediate instructions
 to include a
 third RC register i.e. reinterpret the normal
@@ -67,3 +75,7 @@ Normally, Scalar Instructions have a good justification for being
 added as Scalar instructions on their own merit. `mv.x` is the
 polar opposite, and as such qualifies for a special mention in
 this section.
+
+# Branch-Conditional
+
+[[sv/branches]]