# New instructions for CR/INT predication
+**DRAFT STATUS**
+
See:
* main bugreport for crweirds
# Bit ordering.
-IBM chose MSB0 for the OpenPOWER v3.0B specification. This makes things slightly hair-raising. Our desire initially is therefore to follow the logical progression from the defined behaviour of `mtcr` and `mfcr` etc.
-In [[isa/sprset]] we see the pseudocode for `mtcrf` for example:
-
- mtcrf FXM,RS
-
- do n = 0 to 7
- if FXM[n] = 1 then
- CR[4*n+32:4*n+35] <- (RS)[4*n+32:4*n+35]
-
-This places (according to a mask schedule) `CR0` into MSB0-numbered bits 32-35 of the target Integer register `RS`, these bits of `RS` being the 31st down to the 28th. Unfortunately, even when not Vectorised, this inserts CR numbering inversions on each batch of 8 CRs, massively complicating matters. Predication when using CRs would have to be morphed to this (unacceptably complex) behaviour:
-
- for i in range(VL):
- if INTpredmode:
- predbit = (r3)[63-i] # IBM MSB0 spec sigh
- else:
- # completely incomprehensible vertical numbering
- n = (7-(i%8)) | (i & ~0x7) # total mess
- CRpredicate = CR{n} # select CR0, CR1, ....
- predbit = CRpredicate[offs] # select eq..ov bit
-
-Which is nowhere close to matching the straightforward obvious case:
-
- for i in range(VL):
- if INTpredmode:
- predbit = (r3)[63-i] # IBM MSB0 spec sigh
- else:
- CRpredicate = CR{i} # start at CR0, work up
- predbit = CRpredicate[offs]
-
-In other words unless we do something about this, when we transfer bits from an Integer Predicate into a Vector of CRs, our numbering of CRs, when enumerating them in a CR Vector, would be **CR7** CR6 CR5.... CR0 **CR15** CR14 CR13... CR8 **CR23** CR22 etc. **not** the more natural and obvious CR0 CR1 ... CR23.
-
-Therefore the instructions below need to **redefine** the relationship so that CR numbers (CR0, CR1) sequentially match the arithmetically-ordered bits of Integer registers. By `arithmetic` this is deduced from the fact that the instruction `addi r3, r0, 1` will result in the **LSB** (numbered 63 in IBM MSB0 order) of r3 being set to 1 and all other bits set to zero. We therefore refer, below, to this LSB as "Arithmetic bit 0", and it is this bit which is used - defined - as being the first bit used in Integer predication (on element 0).
-
-Below is some pseudocode that, given a CR offset `offs` to represent `CR.eq` thru to `CR.ov` respectively, will copy the INT predicate bits in the correct order into the first 8 CRs:
+IBM chose MSB0 for the OpenPOWER v3.0B specification. This makes things slightly hair-raising and the relationship between the CR and the CR Field
+numbers is not clearly defined. To make it clear we define a new
+term, `CR{n}`.
+`CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:
- do n = 0 to 7
- CR[4*n+32+offs] <- (RS)[63-n]
-
-Assuming that `offs` is set to `CR.eq` this results in:
-
-* Arithmetic bit 0 (the LSB, numbered 63 in IBM MSB0 terminology)
- of RS being inserted into CR0.eq
-* Arithmetic bit 1 of RS being inserted into CR1.eq
-* ...
-* 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, using `CR{fieldnum}` to refer to the individual CR Fields. 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.
+ CR{7-n} = CR[32+n*4:35+n*4]
+Also note that for SVP64 the relationship for the sequential
+numbering of elements is to the CR **fields** within
+the CR Register, not to individual bits within the CR register.
# Instruction form and pseudocode
-Note that `CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:
-
- CR{7-n} = CR[32+n*4:35+n*4]
-
-Instruction format:
+**DRAFT** Instruction format (use of MAJOR 19 not approved by
+OPF ISA WG):
|0-5|6-10 |11|12-15|16-18|19-20|21-25 |26-30 |31|name |
|---|---- |--|-----|-----|-----|----- |----- |--|---- |
-|19 |RT | |mask |BB | |XO[0:4]|XO[5:9]|/ | |
-|19 |RT |0 |mask |BB | 0 M |XO[0:4]|0 mode |Rc|crrweird |
-|19 |RA |1 |mask |BT | 0 / |XO[0:4]|0 mode |/ |mtcrweird |
-|19 |BT //|0 |mask |BB | 1 / |XO[0:4]|0 mode |/ |crweird |
-|19 |BFT |1 |mask |BB | 1 M |XO[0:4]|0 mode |/ |crweirder |
+|19 |RT | |mask |BFA | |XO[0:4]|XO[5:9]|/ | |
+|19 |RT |M |mask |BFA | 0 0 |XO[0:4]|0 mode |Rc|crrweird |
+|19 |RA |M |mask |BF | 0 1 |XO[0:4]|0 mode |/ |mtcrweird |
+|19 |BFT//|M |mask |BFA | 1 0 |XO[0:4]|0 mode |/ |crweirder |
+|19 |BF |M |mask |BFA | 1 1 |XO[0:4]|0 mode |/ |crweird |
**crrweird**
mode is encoded in XO and is 4 bits
-bit 11=0, bit 19=0
+bit 19=0, bit 20=0
- crrweird: RT, BB, mask.mode
+ crrweird: RT, BFA, M, mask.mode
- creg = CR{BB}
+ creg = CR{BFA}
n0 = mask[0] & (mode[0] == creg[0])
n1 = mask[1] & (mode[1] == creg[1])
n2 = mask[2] & (mode[2] == creg[2])
**mtcrweird**
-bit 11=1, bit 19=0
+bit 19=0, bit 20=1
- mtcrweird: BT, RA, mask.mode
+ mtcrweird: BF, RA, M, mask.mode
reg = (RA|0)
lsb = reg[63] # MSB0 numbering
n1 = mask[1] & (mode[1] == lsb)
n2 = mask[2] & (mode[2] == lsb)
n3 = mask[3] & (mode[3] == lsb)
- CR{BT} = n0 || n1 || n2 || n3
+ result = n0 || n1 || n2 || n3
+ if M:
+ result |= CR{BF} & ~mask
+ CR{BF} = result
+
+Note that when M=1 this operation is a Read-Modify-Write on the CR Field
+BF. Masked-out bits of the 4-bit CR Field BF will not be changed when
+M=1. Correspondingly when M=0 this operation is an overwrite: no read
+of BF is required because the masked-out bits of the BF CR Field are
+set to zero.
When used with SVP64 Prefixing this is a [[openpower/sv/cr_ops]] SVP64 type operation that has
3-bit Data-dependent and 3-bit Predicate-result capability
-(BT is 3 bits)
+(BF is 3 bits)
**crweird**
-bit 11=0, bit 19=1
+bit 19=1, bit 20=0
- crweird: BT, BB, mask.mode
+ crweird: BF, BFA, M, mask.mode
- creg = CR{BB}
+ creg = CR{BFA}
n0 = mask[0] & (mode[0] == creg[0])
n1 = mask[1] & (mode[1] == creg[1])
n2 = mask[2] & (mode[2] == creg[2])
n3 = mask[3] & (mode[3] == creg[3])
- CR{BT} = n0 || n1 || n2 || n3
+ result = n0 || n1 || n2 || n3
+ if M:
+ result |= CR{BF} & ~mask
+ CR{BF} = result
+
+Note that when M=1 this operation is a Read-Modify-Write on the CR Field
+BF. Masked-out bits of the 4-bit CR Field BF will not be changed when
+M=1. Correspondingly when M=0 this operation is an overwrite: no read
+of BF is required because the masked-out bits of the BF CR Field are
+set to zero.
When used with SVP64 Prefixing this is a [[openpower/sv/cr_ops]] SVP64 type operation that has
3-bit Data-dependent and 3-bit Predicate-result capability
-(BT is 3 bits)
+(BF is 3 bits)
**crweirder**
-bit 11=1, bit 19=1
+bit 19=1, bit 20=1
- crweirder: BFT, BB, mask.mode
+ crweirder: BT, BFA, mask.mode
- creg = CR{BB}
+ creg = CR{BFA}
n0 = mask[0] & (mode[0] == creg[0])
n1 = mask[1] & (mode[1] == creg[1])
n2 = mask[2] & (mode[2] == creg[2])
n3 = mask[3] & (mode[3] == creg[3])
- BF = BFT[2:4] # select CR
- bit = BFT[0:1] # select bit of CR
+ BF = BT[2:4] # select CR
+ bit = BT[0:1] # select bit of CR
result = n0|n1|n2|n3 if M else n0&n1&n2&n3
CR{BF}[bit] = result
**Example Pseudo-ops:**
- mtcri BB, mode mtcrweird r0, BB, 0b1111.~mode
- mtcrset BB, mask mtcrweird r0, BB, mask.0b0000
- mtcrclr BB, mask mtcrweird r0, BB, mask.0b1111
+ mtcri BF, mode mtcrweird BF, r0, 0, 0b1111.~mode
+ mtcrset BF, mask mtcrweird BF, r0, 1, mask.0b0000
+ mtcrclr BF, mask mtcrweird BF, r0, 1, mask.0b1111
# Vectorised versions
Normally the progression of the SV for-loop would move on to the next register.
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.
+Further useful violation of the normal SV Elwidth override rules allows
+for packing (or unpacking) of multiple CR test results into
+(or out of) an Integer Element. Note
+that the CR (source operand) elwidth field is utilised to determine the bit-
+packing size (1/2/4/8 with remaining bits within the Integer element
+set to zero) whilst the INT (dest operand) elwidth field still sets
+the Integer element size as usual (8/16/32/default)
+
crrweird: RT, BB, mask.mode
for i in range(VL):
* in the scalar case the CR-Vector assessment
is stored bit-wise starting at the LSB of the
destination scalar INT
-* in the INT-vector case the result is stored in the
- LSB of each element in the result vector
-
-Note that element width overrides are respected on the INT src or destination register, however that it is the CR element-width
-override that is used to indicate how many bits of CR results
-are packed/extracted into/from each INT register
+* in the INT-vector case the results are packed into LSBs
+ of the INT Elements, the packing arrangement depending on both
+ elwidth override settings.
# v3.1 setbc instructions
projects / libreriscv.git / blobdiff