(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index b4618ad1e600fb27889e826d213f2df8697e2470..a9f4c6f7529996165ff8277ddc7e2f250187225c 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -27,15 +27,17 @@ 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. 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
+that when elwidth=8 in the Prefix it's an *8-bit* add-with-carry.
+In other words, elwidth overrides **definitely** do not fundamentally
+alter the actual
+Scalar v3.0 ISA encoding itself.  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.
+for example, and under absolutely no circumstances do the actual 32-bit
+Scalar v3.0 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