(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 7284a21473d6fb0f3f20ff8cf13ee89b8a88e6b6..f95cb992c847394a619784838c27c18af1726d47 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -26,11 +26,16 @@ The modification caveat in (2) above semantically
 exempts element width overrides,
 which still do not actually modify the meaning of the instruction:
 an add remains an add, even if its override makes it an 8-bit add rather than
-a 64-bit add. elwidth overrides *definitely* do not alter the actual
-Scalar v3.0 ISA encoding itself.
-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.
+a 64-bit add. Even add-with-carry remains an add-with-carry: it's just
+that it's an *8-bit* add-with-carry.
+In other words, elwidth overrides *definitely* do not alter the actual
+Scalar v3.0 ISA encoding itself, and consequently we can still, in
+the strictest sense, not be breaking rule (2).
+Likewise, other "modifications" such as saturation or Data-dependent
+Fail-First likewise are actually post-augmentation or post-analysis, and do
+not fundamentally change an add operation into a subtract
+for example, and under absolutely no circumstances do the actual
+operand field bits change or the number of operands change.
 
 *(In an early Draft of SVP64,
 an experiment was attempted, to modify LD-immediate instructions