(no commit message)

diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn
index b8c860b25f7e467dc0f2e2b124b034bab29c5c41..8b510c2d89ceb57efc981946353d1032d9ae8e58 100644 (file)
--- a/openpower/sv/rfc/ls001.mdwn
+++ b/openpower/sv/rfc/ls001.mdwn
@@ -423,15 +423,16 @@ much more powerful with the
 operations, and secondly by adding powerful binary and ternary CR Field
 operations into the bitmanip extension.[^crops]
 
-On top of these additional instructions, RM Modes may still be applied, particularly mapreduce and Data-Dependent Fail-first.  The usefulness of
+On these instructions RM Modes may still be applied (mapreduce and Data-Dependent Fail-first).  The usefulness of
 being able to auto-truncate subsequent Vector Processing at the point
-at which a CR Field test fails should be very clear.
-
-With element-width overrides being meaningless for CR Fields the
-decision to use those bits in RM for other purposes was an easy one.
-This does provide more uniformity and flexibility to CR Field
-operations, but there are less options: neither Saturation nor
-Predicate-Result make sense.
+at which a CR Field test fails, based on any arbitary logical operation involving `three` CR Field Vectors (`crternlogi`) should be clear, as
+should the benefits of being able to do mapreduce and REMAP Parallel
+Reduction on `crternlogi`: dramatic reduction in instruction count
+for Branch-based control flow when faced with complex analysis of
+multiple Vectors.
+
+Overall the addition of the CR Operations and the CR RM Modes is about
+getting instruction count down and increasing the power and flexibility of CR Fields as pressed into service for the purpose of Predicate Masks.
 
 [^crops]: the alternative to powerful transfer instructions between GPR and CR Fields was to add the full duplicated suite of BMI and TBM operations present in GPR (popcnt, cntlz, set-before-first) as CR Field Operations. all of which was deemed inappropriate.