(no commit message)
[libreriscv.git] / openpower / sv / cr_int_predication.mdwn
1 [[!tag standards]]
2
3 # New instructions for CR/INT predication
4
5 See:
6
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=533>
8 * <https://bugs.libre-soc.org/show_bug.cgi?id=527>
9 * <https://bugs.libre-soc.org/show_bug.cgi?id=569>
10 * <https://bugs.libre-soc.org/show_bug.cgi?id=558#c47>
11
12 Rationale:
13
14 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.
15
16 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.
17
18 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.
19
20 Basic concept:
21
22 * CR-based instructions that perform simple AND/OR/XOR from all four bits
23 of a CR to create a single bit value (0/1) in an integer register
24 * Inverse of the same, taking a single bit value (0/1) from an integer
25 register to selectively target all four bits of a given CR
26 * CR-to-CR version of the same, allowing multiple bits to be AND/OR/XORed
27 in one hit.
28 * Vectorisation of the same
29
30 Purpose:
31
32 * To provide a merged version of what is currently a multi-sequence of
33 CR operations (crand, cror, crxor) with mfcr and mtcrf, reducing
34 instruction count.
35 * To provide a vectorised version of the same, suitable for advanced
36 predication
37
38 Side-effects:
39
40 * mtcrweird when RA=0 is a means to set or clear arbitrary CR bits from immediates
41
42 (Twin) Predication interactions:
43
44 * INT twin predication with zeroing is a way to copy an integer into CRs without necessarily needing the INT register (RA). if it is, it is effectively ANDed (or negate-and-ANDed) with the INT Predicate
45 * CR twin predication with zeroing is likewise a way to interact with the incoming integer
46
47 this gets particularly powerful if data-dependent predication is also enabled.
48
49 # Bit ordering.
50
51 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.
52 In [[isa/sprset]] we see the pseudocode for `mtcrf` for example:
53
54 mtcrf FXM,RS
55
56 do n = 0 to 7
57 if FXM[n] = 1 then
58 CR[4*n+32:4*n+35] <- (RS)[4*n+32:4*n+35]
59
60 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:
61
62 for i in range(VL):
63 if INTpredmode:
64 predbit = (r3)[63-i] # IBM MSB0 spec sigh
65 else:
66 # completely incomprehensible vertical numbering
67 n = (7-(i%8)) | (i & ~0x7) # total mess
68 CRpredicate = CR{n} # select CR0, CR1, ....
69 predbit = CRpredicate[offs] # select eq..ov bit
70
71 Which is nowhere close to matching the straightforward obvious case:
72
73 for i in range(VL):
74 if INTpredmode:
75 predbit = (r3)[63-i] # IBM MSB0 spec sigh
76 else:
77 CRpredicate = CR{i} # start at CR0, work up
78 predbit = CRpredicate[offs]
79
80 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.
81
82 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).
83
84 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:
85
86 do n = 0 to 7
87 CR[4*n+32+offs] <- (RS)[63-n]
88
89 Assuming that `offs` is set to `CR.eq` this results in:
90
91 * Arithmetic bit 0 (the LSB, numbered 63 in IBM MSB0 terminology)
92 of RS being inserted into CR0.eq
93 * Arithmetic bit 1 of RS being inserted into CR1.eq
94 * ...
95 * Arithmetic bit 7 of RS being inserted into CR7.eq
96
97 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.
98
99
100 # Instruction form and pseudocode
101
102 Note that `CR{n}` refers to `CR0` when `n=0` and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:
103
104 CR{7-n} = CR[32+n*4:35+n*4]
105
106 Instruction format:
107
108 | 0-5 | 6-10 | 11 | 12-15 | 16-18 | 19-20 | 21-25 | 26-30 | 31 |
109 | --- | ---- | -- | ----- | ----- | ----- | ----- | ----- | -- |
110 | 19 | RT | | mask | BB | | XO[0:4] | XO[5:9] | / |
111 | 19 | RT | 0 | mask | BB | 0 M | XO[0:4] | 0 mode | Rc |
112 | 19 | RA | 1 | mask | BB | 0 / | XO[0:4] | 0 mode | / |
113 | 19 | BT // | 0 | mask | BB | 1 / | XO[0:4] | 0 mode | / |
114 | 19 | BFT | 1 | mask | BB | 1 M | XO[0:4] | 0 mode | / |
115
116 mode is encoded in XO and is 4 bits
117
118 bit 11=0, bit 19=0
119
120 crrweird: RT, BB, mask.mode
121
122 creg = CR{BB}
123 n0 = mask[0] & (mode[0] == creg[0])
124 n1 = mask[1] & (mode[1] == creg[1])
125 n2 = mask[2] & (mode[2] == creg[2])
126 n3 = mask[3] & (mode[3] == creg[3])
127 result = n0|n1|n2|n3 if M else n0&n1&n2&n3
128 RT[63] = result # MSB0 numbering, 63 is LSB
129 If Rc:
130 CR1 = analyse(RT)
131
132 bit 11=1, bit 19=0
133
134 mtcrweird: RA, BB, mask.mode
135
136 reg = (RA|0)
137 lsb = reg[63] # MSB0 numbering
138 n0 = mask[0] & (mode[0] == lsb)
139 n1 = mask[1] & (mode[1] == lsb)
140 n2 = mask[2] & (mode[2] == lsb)
141 n3 = mask[3] & (mode[3] == lsb)
142 CR{BB} = n0 || n1 || n2 || n3
143
144 bit 11=0, bit 19=1
145
146 crweird: BT, BB, mask.mode
147
148 creg = CR{BB}
149 n0 = mask[0] & (mode[0] == creg[0])
150 n1 = mask[1] & (mode[1] == creg[1])
151 n2 = mask[2] & (mode[2] == creg[2])
152 n3 = mask[3] & (mode[3] == creg[3])
153 CR{BT} = n0 || n1 || n2 || n3
154
155 bit 11=1, bit 19=1
156
157 crweirder: BFT, BB, mask.mode
158
159 creg = CR{BB}
160 n0 = mask[0] & (mode[0] == creg[0])
161 n1 = mask[1] & (mode[1] == creg[1])
162 n2 = mask[2] & (mode[2] == creg[2])
163 n3 = mask[3] & (mode[3] == creg[3])
164 BF = BFT[2:4] # select CR
165 bit = BFT[0:1] # select bit of CR
166 result = n0|n1|n2|n3 if M else n0&n1&n2&n3
167 CR{BF}[bit] = result
168
169 Pseudo-op:
170
171 mtcri BB, mode mtcrweird r0, BB, 0b1111.~mode
172 mtcrset BB, mask mtcrweird r0, BB, mask.0b0000
173 mtcrclr BB, mask mtcrweird r0, BB, mask.0b1111
174
175
176 # Vectorised versions
177
178 The name "weird" refers to a minor violation of SV rules when it comes to deriving the Vectorised versions of these instructions.
179
180 Normally the progression of the SV for-loop would move on to the next register.
181 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.
182
183 crrweird: RT, BB, mask.mode
184
185 for i in range(VL):
186 if BB.isvec:
187 creg = CR{BB+i}
188 else:
189 creg = CR{BB}
190 n0 = mask[0] & (mode[0] == creg[0])
191 n1 = mask[1] & (mode[1] == creg[1])
192 n2 = mask[2] & (mode[2] == creg[2])
193 n3 = mask[3] & (mode[3] == creg[3])
194 result = n0|n1|n2|n3 if M else n0&n1&n2&n3
195 if RT.isvec:
196 iregs[RT+i][63] = result
197 else:
198 iregs[RT][63-i] = result
199
200 Note that:
201
202 * in the scalar case the CR-Vector assessment
203 is stored bit-wise starting at the LSB of the
204 destination scalar INT
205 * in the INT-vector case the result is stored in the
206 LSB of each element in the result vector
207
208 Note that element width overrides are respected on the INT src or destination register (but that elwidth overrides on CRs are meaningless)