(no commit message)

diff --git a/openpower/sv/mv.swizzle.mdwn b/openpower/sv/mv.swizzle.mdwn
index 958231ad5447d35df44041478012ac749721534c..b6b121875387a16662bd9b8a9282efc0840a0854 100644 (file)
--- a/openpower/sv/mv.swizzle.mdwn
+++ b/openpower/sv/mv.swizzle.mdwn
@@ -174,13 +174,15 @@ may be assumed to be 4.
 
 **Effect of Saturation on Vectorised Swizzle**
 
-```
-one thing that occurred to me: we need fmv.swizzle and maybe mvfixed[u].swizzle too (integers where 0.0 maps to 0 and 1.0 maps to the max signed/unsigned integer -- used for fixed-point swizzle such as pixel data -- we need signed ints for efficient bump map support for some programs). the 0.0 and 1.0 constants should map to 0, 1 for mv.swizzle, 0.0, 1.0 for fmv.swizzle, 0, UINT_MAX for mvfixedu.swizzle, and 0, INT_MAX for mvfixed.swizzle.
-
-i like the idea of a SKIP option!
-
-Jacob
-```
+A useful convenience for pixel data is to be able to insert values
+0x7f or 0xff as magic constants for arbitrary R,G,B or A. Therefore,
+when Saturation is enabled and a Swizzle=0b011 (Constant 1) is requested,
+the maximum permitted Saturated value is inserted rather than Constant 1.
+`sv.mv.swiz/sats/vec2/ew=8 RT.v, RA.v, Y1` would insert the 2nd subelement
+(Y) into the first destination subelement and the signed-maximum constant
+0x7f into the second. A Constant 0 Swizzle on the other hand still inserts
+zero because there is no encoding space to select between -1, 0 and 1, and
+0 and max values are more useful.
 
 # RM Mode Concept: