(no commit message)
[libreriscv.git] / openpower / sv / cr_int_predication.mdwn
index 96b9dcfd48779ce8728e5906d7f5cbb1a5df3d89..baac0fe9a66004573959bc69f2635a94940ff31d 100644 (file)
@@ -11,10 +11,12 @@ See:
 
 Rationale:
 
-Condition Registers are conceptually perfect for use as predicate masks, the only problem being that typical Vector ISAs have quite comprehensive mask-based instructions: set-before-first, popcount and much more.  In fact many Vector ISAs can use Vectors *as* masks.  This is not practical for SV given the premise to minimise adding of instructions.
+Condition Registers are conceptually perfect for use as predicate masks, the only problem being that typical Vector ISAs have quite comprehensive mask-based instructions: set-before-first, popcount and much more.  In fact many Vector ISAs can use Vectors *as* masks, consequently the entire Vector ISA is available for use in creating masks.  This is not practical for SV given the premise to minimise adding of instructions.
 
 With the scalar OpenPOWER v3.0B ISA having already popcnt, cntlz and others normally seen in Vector Mask operations it makes sense to allow *both* scalar integers *and* CR-Vectors to be predicate masks.  That in turn means that much more comprehensive interaction between CRs and scalar Integers is required.
 
+The opportunity is therefore taken to also augment CR logical arithmetic as well, using a mask-based paradigm that takes into consideration multiple bits of each CR (eq/lt/gt/ov).  v3.0B Scalar CR instructions (crand, crxor) only allow a single bit calculation.
+
 Basic concept:
 
 * CR-based instructions that perform simple AND/OR/XOR from all four bits
@@ -92,7 +94,7 @@ Assuming that `offs` is set to `CR.eq` this results in:
 * ...
 * Arithmetic bit 7 of RS being inserted into CR7.eq
 
-To clarify, then: all instructions below do **NOT** follow the IBM convention, they follow the natural sequence CR0 CR1 instead.  However it is critically important to note that the offsets **in** a CR (`CR.eq` for example) continue to follow the v3.0B definition and convention.
+To clarify, then: all instructions below do **NOT** follow the IBM convention, they follow the natural sequence CR0 CR1 instead, using `CR{fieldnum}` to refer to the individual CR Firlds.  However it is critically important to note that the offsets **in** a CR field (`CR.eq` for example) continue to follow the v3.0B definition and convention.
 
 
 # Instruction form and pseudocode
@@ -105,11 +107,11 @@ Instruction format:
 
     | 0-5 | 6-10  | 11 | 12-15 | 16-18 | 19-20 | 21-25   | 26-30   | 31 |
     | --- | ----  | -- | ----- | ----- | ----- | -----   | -----   | -- |
-    | 19  | RT    |    | mask  | BB    |    /  | XO[0:4] | XO[5:9] | /  |
-    | 19  | RT    | 0  | mask  | BB    |  0 /  | XO[0:4] | 0 mode  | /  |
+    | 19  | RT    |    | mask  | BB    |       | XO[0:4] | XO[5:9] | /  |
+    | 19  | RT    | 0  | mask  | BB    |  0 M  | XO[0:4] | 0 mode  | Rc |
     | 19  | RA    | 1  | mask  | BB    |  0 /  | XO[0:4] | 0 mode  | /  |
     | 19  | BT // | 0  | mask  | BB    |  1 /  | XO[0:4] | 0 mode  | /  |
-    | 19  | BFT   | 1  | mask  | BB    |  1 /  | XO[0:4] | 0 mode  | /  |
+    | 19  | BFT   | 1  | mask  | BB    |  1 M  | XO[0:4] | 0 mode  | /  |
 
 mode is encoded in XO and is 4 bits
 
@@ -122,7 +124,10 @@ bit 11=0, bit 19=0
     n1 = mask[1] & (mode[1] == creg[1])
     n2 = mask[2] & (mode[2] == creg[2])
     n3 = mask[3] & (mode[3] == creg[3])
-    RT[63] = n0|n1|n2|n3 # MSB0 numbering, 63 is LSB
+    result = n0|n1|n2|n3 if M else n0&n1&n2&n3
+    RT[63] = result # MSB0 numbering, 63 is LSB
+    If Rc:
+        CR1 = analyse(RT)
 
 bit 11=1, bit 19=0
 
@@ -158,7 +163,8 @@ bit 11=1, bit 19=1
     n3 = mask[3] & (mode[3] == creg[3])
     BF = BFT[2:4] # select CR
     bit = BFT[0:1] # select bit of CR
-    CR{BF}[bit] = n0|n1|n2|n3
+    result = n0|n1|n2|n3 if M else n0&n1&n2&n3
+    CR{BF}[bit] = result
 
 Pseudo-op:
 
@@ -172,7 +178,7 @@ Pseudo-op:
 The name "weird" refers to a minor violation of SV rules when it comes to deriving the Vectorised versions of these instructions.
 
 Normally the progression of the SV for-loop would move on to the next register.
-Instead however these instructions **remain in the same register** and insert or transfer between **bits** of the scalar integer source or destination.
+Instead however in the scalar case these instructions **remain in the same register** and insert or transfer between **bits** of the scalar integer source or destination.
 
     crrweird: RT, BB, mask.mode
 
@@ -185,10 +191,11 @@ Instead however these instructions **remain in the same register** and insert or
         n1 = mask[1] & (mode[1] == creg[1])
         n2 = mask[2] & (mode[2] == creg[2])
         n3 = mask[3] & (mode[3] == creg[3])
+        result = n0|n1|n2|n3 if M else n0&n1&n2&n3
         if RT.isvec:
-            iregs[RT+i][63] = n0|n1|n2|n3
+            iregs[RT+i][63] = result
         else:
-            iregs[RT][63-i] = n0|n1|n2|n3
+            iregs[RT][63-i] = result
 
 Note that:
 
@@ -199,3 +206,13 @@ Note that:
   LSB of each element in the result vector
 
 Note that element width overrides are respected on the INT src or destination register (but that elwidth overrides on CRs are meaningless)
+
+# v3.1 setbc instructions
+
+there are additional setb conditional instructions in v3.1 (p129)
+
+    RT = (CR[BI] == 1) ? 1 : 0
+
+which also negate that, and also return -1 / 0.  these are similar yo crweird but not the same purpose.  most notable is that crweird acts on CR fields rather than the entire 32 bit CR.
+
+