CR-related SVP64 ops

diff --git a/openpower/sv/cr_ops.mdwn b/openpower/sv/cr_ops.mdwn
new file mode 100644 (file)
index 0000000..356be13
--- /dev/null
+++ b/openpower/sv/cr_ops.mdwn
@@ -0,0 +1,40 @@
+# Data-dependent fail-first on CR operations (crand etc)
+
+Operations that actually produce or alter CR Field as a result
+do not also in turn have an Rc=1 mode.  However it makes no
+sense to try to test the 4 bits of a CR Field for being equal
+or not equal to zero. Moreover, the result is already in the
+form that is desired: it is a CR field.
+
+There are two primary different types of CR operations:
+
+* Those which have a 3-bit operand field (referring to a CR Field)
+* Those which have a 5-bit operand (referring to a bit within the
+   whole 32-bit CR)
+
+Examining these two as has already been done it is observed that
+the difference may be considered to be that the 5-bit variant
+provides additional information about which CR Field bit
+(EQ, GE, LT, SO) is to be operated on by the instruction.
+
+Thus, logically, we may set the following rule:
+
+* When a 5-bit CR Result field is used in an instruction, the
+  `inv, VLi and RC1` variant of Data-Dependent Fail-First
+  must be used. i.e. the bit of the CR field to be tested is
+  the one that has just been modified by the operation.
+* When a 3-bit CR Result field is used the `inv CRbit` variant
+  must be used in order to select which CR Field bit shall
+  be tested (EQ, LE, GE, SO).
+
+Examples of the former type:
+
+* crand, cror, crnor. These all are 5-bit (BA, BB, BT). The bit
+  to be tested against `inv` is the one selected by `BT`
+* mcrf. This has only 3-bit (BF, BFA). In order to select the
+  bit to be tested, the alternative FFirst encoding must be used.
+
+This limits sv.mcrf in that it may not use the `VLi` (VL inclusive)
+Mode. This is unfortunste but unavoidable due to encoding pressure
+on SVP64.
+