7 * ternlogi <https://bugs.libre-soc.org/show_bug.cgi?id=745>
8 * grev <https://bugs.libre-soc.org/show_bug.cgi?id=755>
9 * GF2^M <https://bugs.libre-soc.org/show_bug.cgi?id=782>
10 * binutils <https://bugs.libre-soc.org/show_bug.cgi?id=836>
11 * shift-and-add <https://bugs.libre-soc.org/show_bug.cgi?id=968>
17 pseudocode: [[openpower/isa/bitmanip]]
19 this extension amalgamates bitmanipulation primitives from many sources,
20 including RISC-V bitmanip, Packed SIMD, AVX-512 and OpenPOWER VSX.
21 Also included are DSP/Multimedia operations suitable for Audio/Video.
22 Vectorisation and SIMD are removed: these are straight scalar (element)
23 operations making them suitable for embedded applications. Vectorisation
24 Context is provided by [[openpower/sv]].
26 When combined with SV, scalar variants of bitmanip operations found in
27 VSX are added so that the Packed SIMD aspects of VSX may be retired as
28 "legacy" in the far future (10 to 20 years). Also, VSX is hundreds of
29 opcodes, requires 128 bit pathways, and is wholly unsuited to low power
30 or embedded scenarios.
32 ternlogv is experimental and is the only operation that may be considered
33 a "Packed SIMD". It is added as a variant of the already well-justified
34 ternlog operation (done in AVX512 as an immediate only) "because it
35 looks fun". As it is based on the LUT4 concept it will allow accelerated
36 emulation of FPGAs. Other vendors of ISAs are buying FPGA companies to
37 achieve similar objectives.
39 general-purpose Galois Field 2^M operations are added so as to avoid
40 huge custom opcode proliferation across many areas of Computer Science.
41 however for convenience and also to avoid setup costs, some of the more
42 common operations (clmul, crc32) are also added. The expectation is
43 that these operations would all be covered by the same pipeline.
45 note that there are brownfield spaces below that could incorporate
46 some of the set-before-first and other scalar operations listed in
48 [[sv/vector_ops]], [[sv/int_fp_mv]] and the [[sv/av_opcodes]] as well as
49 [[sv/setvl]], [[sv/svstep]], [[sv/remap]]
53 * <https://en.wikiversity.org/wiki/Reed%E2%80%93Solomon_codes_for_coders>
54 * <https://maths-people.anu.edu.au/~brent/pd/rpb232tr.pdf>
55 * <https://gist.github.com/animetosho/d3ca95da2131b5813e16b5bb1b137ca0>
56 * <https://github.com/HJLebbink/asm-dude/wiki/GF2P8AFFINEINVQB>
58 [[!inline pages="openpower/sv/draft_opcode_tables" quick="yes" raw="yes" ]]
60 # binary and ternary bitops
62 Similar to FPGA LUTs: for two (binary) or three (ternary) inputs take
63 bits from each input, concatenate them and perform a lookup into a
64 table using an 8-8-bit immediate (for the ternary instructions), or in
65 another register (4-bit for the binary instructions). The binary lookup
66 instructions have CR Field lookup variants due to CR Fields being 4 bit.
69 [vpternlogd/vpternlogq](https://www.felixcloutier.com/x86/vpternlogd:vpternlogq)
74 | 0.5|6.10|11.15|16.20| 21..28|29.30|31|
75 | -- | -- | --- | --- | ----- | --- |--|
76 | NN | RT | RA | RB | im0-7 | 00 |Rc|
79 idx = c << 2 | b << 1 | a
80 return imm[idx] # idx by LSB0 order
83 RT[i] = lut3(imm, RB[i], RA[i], RT[i])
87 Binary lookup is a dynamic LUT2 version of ternlogi. Firstly, the
88 lookup table is 4 bits wide not 8 bits, and secondly the lookup
89 table comes from a register not an immediate.
91 | 0.5|6.10|11.15|16.20| 21..25|26..31 | Form |
92 | -- | -- | --- | --- | ----- |--------|---------|
93 | NN | RT | RA | RB | RC |nh 00001| VA-Form |
94 | NN | RT | RA | RB | /BFA/ |0 01001| VA-Form |
96 For binlut, the 4-bit LUT may be selected from either the high nibble
97 or the low nibble of the first byte of RC:
101 return imm[idx] # idx by LSB0 order
103 imm = (RC>>(nh*4))&0b1111
105 RT[i] = lut2(imm, RB[i], RA[i])
107 For bincrlut, `BFA` selects the 4-bit CR Field as the LUT2:
110 RT[i] = lut2(CRs{BFA}, RB[i], RA[i])
112 When Vectorised with SVP64, as usual both source and destination may be
115 *Programmer's note: a dynamic ternary lookup may be synthesised from
116 a pair of `binlut` instructions followed by a `ternlogi` to select which
117 to merge. Use `nh` to select which nibble to use as the lookup table
118 from the RC source register (`nh=1` nibble high), i.e. keeping
119 an 8-bit LUT3 in RC, the first `binlut` instruction may set nh=0 and
124 another mode selection would be CRs not Ints.
126 | 0.5|6.8 | 9.11|12.14|15.17|18.20|21.28 | 29.30|31|
127 | -- | -- | --- | --- | --- |-----|----- | -----|--|
128 | NN | BT | BA | BB | BC |m0-2 | imm | 01 |m3|
132 a,b,c = CRs[BA][i], CRs[BB][i], CRs[BC][i])
133 if mask[i] CRs[BT][i] = lut3(imm, a, b, c)
135 This instruction is remarkably similar to the existing crops, `crand` etc.
136 which have been noted to be a 4-bit (binary) LUT. In effect `crternlogi`
137 is the ternary LUT version of crops, having an 8-bit LUT.
141 With ternary (LUT3) dynamic instructions being very costly,
142 and CR Fields being only 4 bit, a binary (LUT2) variant is better
144 | 0.5|6.8 | 9.11|12.14|15.17|18.21|22...30 |31|
145 | -- | -- | --- | --- | --- |-----| -------- |--|
146 | NN | BT | BA | BB | BC |m0-m3|000101110 |0 |
150 a,b = CRs[BA][i], CRs[BB][i])
151 if mask[i] CRs[BT][i] = lut2(CRs[BC], a, b)
153 When SVP64 Vectorised any of the 4 operands may be Scalar or
154 Vector, including `BC` meaning that multiple different dynamic
155 lookups may be performed with a single instruction.
157 *Programmer's note: just as with binlut and ternlogi, a pair
158 of crbinlog instructions followed by a merging crternlogi may
159 be deployed to synthesise dynamic ternary (LUT3) CR Field
166 required for the [[sv/av_opcodes]]
168 signed and unsigned min/max for integer. this is sort-of partly
169 synthesiseable in [[sv/svp64]] with pred-result as long as the dest reg
170 is one of the sources, but not both signed and unsigned. when the dest
171 is also one of the srces and the mv fails due to the CR bittest failing
172 this will only overwrite the dest where the src is greater (or less).
174 signed/unsigned min/max gives more flexibility.
178 * XO=0001001110, itype=0b00 min, unsigned
179 * XO=0101001110, itype=0b01 min, signed
180 * XO=0011001110, itype=0b10 max, unsigned
181 * XO=0111001110, itype=0b11 max, signed
185 uint_xlen_t mins(uint_xlen_t rs1, uint_xlen_t rs2)
186 { return (int_xlen_t)rs1 < (int_xlen_t)rs2 ? rs1 : rs2;
188 uint_xlen_t maxs(uint_xlen_t rs1, uint_xlen_t rs2)
189 { return (int_xlen_t)rs1 > (int_xlen_t)rs2 ? rs1 : rs2;
191 uint_xlen_t minu(uint_xlen_t rs1, uint_xlen_t rs2)
192 { return rs1 < rs2 ? rs1 : rs2;
194 uint_xlen_t maxu(uint_xlen_t rs1, uint_xlen_t rs2)
195 { return rs1 > rs2 ? rs1 : rs2;
201 required for the [[sv/av_opcodes]], these exist in Packed SIMD (VSX)
205 uint_xlen_t intavg(uint_xlen_t rs1, uint_xlen_t rs2) {
206 return (rs1 + rs2 + 1) >> 1:
212 required for the [[sv/av_opcodes]], these exist in Packed SIMD (VSX)
216 uint_xlen_t absdu(uint_xlen_t rs1, uint_xlen_t rs2) {
217 return (src1 > src2) ? (src1-src2) : (src2-src1)
223 required for the [[sv/av_opcodes]], these are needed for motion estimation.
224 both are overwrite on RS.
227 uint_xlen_t uintabsacc(uint_xlen_t rs, uint_xlen_t ra, uint_xlen_t rb) {
228 return rs + (src1 > src2) ? (src1-src2) : (src2-src1)
230 uint_xlen_t intabsacc(uint_xlen_t rs, int_xlen_t ra, int_xlen_t rb) {
231 return rs + (src1 > src2) ? (src1-src2) : (src2-src1)
235 For SVP64, the twin Elwidths allows e.g. a 16 bit accumulator for 8 bit
236 differences. Form is `RM-1P-3S1D` where RS-as-source has a separate
237 SVP64 designation from RS-as-dest. This gives a limited range of
238 non-overwrite capability.
240 # shift-and-add <a name="shift-add"> </a>
242 Power ISA is missing LD/ST with shift, which is present in both ARM and x86.
243 Too complex to add more LD/ST, a compromise is to add shift-and-add.
244 Replaces a pair of explicit instructions in hot-loops.
248 |0 |6 |11 |15 |16 |21 |23 |31 |
249 | PO | RT | RA | RB |sm | XO |Rc |
253 uint_xlen_t shadd(uint_xlen_t rs1, uint_xlen_t rs2, uint8_t sh) {
255 return (rs1 << (sh+1)) + rs2;
258 uint_xlen_t shadduw(uint_xlen_t rs1, uint_xlen_t rs2, uint8_t sh) {
259 uint_xlen_t rs1z = rs1 & 0xFFFFFFFF;
261 return (rs1z << (sh+1)) + rs2;
267 based on RV bitmanip singlebit set, instruction format similar to shift
268 [[isa/fixedshift]]. bmext is actually covered already (shift-with-mask
269 rldicl but only immediate version). however bitmask-invert is not,
270 and set/clr are not covered, although they can use the same Shift ALU.
272 bmext (RB) version is not the same as rldicl because bmext is a right
273 shift by RC, where rldicl is a left rotate. for the immediate version
274 this does not matter, so a bmexti is not required. bmrev however there
275 is no direct equivalent and consequently a bmrevi is required.
277 bmset (register for mask amount) is particularly useful for creating
278 predicate masks where the length is a dynamic runtime quantity.
279 bmset(RA=0, RB=0, RC=mask) will produce a run of ones of length "mask"
280 in a single instruction without needing to initialise or depend on any
283 | 0.5|6.10|11.15|16.20|21.25| 26..30 |31| name |
284 | -- | -- | --- | --- | --- | ------- |--| ----- |
285 | NN | RS | RA | RB | RC | mode 010 |Rc| bm\* |
287 Immediate-variant is an overwrite form:
289 | 0.5|6.10|11.15|16.20| 21 | 22.23 | 24....30 |31| name |
290 | -- | -- | --- | --- | -- | ----- | -------- |--| ---- |
291 | NN | RS | RB | sh | SH | itype | 1000 110 |Rc| bm\*i |
297 mask_a = ((1 << x) - 1) & ((1 << 64) - 1)
298 mask_b = ((1 << y) - 1) & ((1 << 64) - 1)
303 mask_a = ((1 << x) - 1) & ((1 << 64) - 1)
304 mask_b = (~((1 << y) - 1)) & ((1 << 64) - 1)
305 return mask_a ^ mask_b
308 uint_xlen_t bmset(RS, RB, sh)
310 int shamt = RB & (XLEN - 1);
312 return RS | (mask << shamt);
315 uint_xlen_t bmclr(RS, RB, sh)
317 int shamt = RB & (XLEN - 1);
319 return RS & ~(mask << shamt);
322 uint_xlen_t bminv(RS, RB, sh)
324 int shamt = RB & (XLEN - 1);
326 return RS ^ (mask << shamt);
329 uint_xlen_t bmext(RS, RB, sh)
331 int shamt = RB & (XLEN - 1);
333 return mask & (RS >> shamt);
337 bitmask extract with reverse. can be done by bit-order-inverting all
338 of RB and getting bits of RB from the opposite end.
340 when RA is zero, no shift occurs. this makes bmextrev useful for
341 simply reversing all bits of a register.
345 rev[0:msb] = rb[msb:0];
348 uint_xlen_t bmrevi(RA, RB, sh)
351 if (RA != 0) shamt = (GPR(RA) & (XLEN - 1));
352 shamt = (XLEN-1)-shamt; # shift other end
353 brb = bitreverse(GPR(RB)) # swap LSB-MSB
355 return mask & (brb >> shamt);
358 uint_xlen_t bmrev(RA, RB, RC) {
359 return bmrevi(RA, RB, GPR(RC) & 0b111111);
363 | 0.5|6.10|11.15|16.20|21.26| 27..30 |31| name | Form |
364 | -- | -- | --- | --- | --- | ------- |--| ------ | -------- |
365 | NN | RT | RA | RB | sh | 1111 |Rc| bmrevi | MDS-Form |
367 | 0.5|6.10|11.15|16.20|21.25| 26..30 |31| name | Form |
368 | -- | -- | --- | --- | --- | ------- |--| ------ | -------- |
369 | NN | RT | RA | RB | RC | 11110 |Rc| bmrev | VA2-Form |
371 # grevlut <a name="grevlut"> </a>
373 generalised reverse combined with a pair of LUT2s and allowing
374 a constant `0b0101...0101` when RA=0, and an option to invert
375 (including when RA=0, giving a constant 0b1010...1010 as the
376 initial value) provides a wide range of instructions
377 and a means to set hundreds of regular 64 bit patterns with one
378 single 32 bit instruction.
380 the two LUT2s are applied left-half (when not swapping)
381 and right-half (when swapping) so as to allow a wider
384 <img src="/openpower/sv/grevlut2x2.jpg" width=700 />
386 * A value of `0b11001010` for the immediate provides
387 the functionality of a standard "grev".
388 * `0b11101110` provides gorc
390 grevlut should be arranged so as to produce the constants
391 needed to put into bext (bitextract) so as in turn to
392 be able to emulate x86 pmovmask instructions
393 <https://www.felixcloutier.com/x86/pmovmskb>.
394 This only requires 2 instructions (grevlut, bext).
396 Note that if the mask is required to be placed
397 directly into CR Fields (for use as CR Predicate
398 masks rather than a integer mask) then sv.cmpi or sv.ori
399 may be used instead, bearing in mind that sv.ori
400 is a 64-bit instruction, and `VL` must have been
401 set to the required length:
403 sv.ori./elwid=8 r10.v, r10.v, 0
405 The following settings provide the required mask constants:
407 | RA=0 | RB | imm | iv | result |
408 | ------- | ------- | ---------- | -- | ---------- |
409 | 0x555.. | 0b10 | 0b01101100 | 0 | 0x111111... |
410 | 0x555.. | 0b110 | 0b01101100 | 0 | 0x010101... |
411 | 0x555.. | 0b1110 | 0b01101100 | 0 | 0x00010001... |
412 | 0x555.. | 0b10 | 0b11000110 | 1 | 0x88888... |
413 | 0x555.. | 0b110 | 0b11000110 | 1 | 0x808080... |
414 | 0x555.. | 0b1110 | 0b11000110 | 1 | 0x80008000... |
416 Better diagram showing the correct ordering of shamt (RB). A LUT2
417 is applied to all locations marked in red using the first 4
418 bits of the immediate, and a separate LUT2 applied to all
419 locations in green using the upper 4 bits of the immediate.
421 <img src="/openpower/sv/grevlut.png" width=700 />
423 demo code [[openpower/sv/grevlut.py]]
428 return imm[idx] # idx by LSB0 order
430 dorow(imm8, step_i, chunksize, us32b):
431 for j in 0 to 31 if is32b else 63:
432 if (j&chunk_size) == 0
436 step_o[j] = lut2(imm, step_i[j], step_i[j ^ chunk_size])
439 uint64_t grevlut(uint64_t RA, uint64_t RB, uint8 imm, bool iv, bool is32b)
441 uint64_t x = 0x5555_5555_5555_5555;
442 if (RA != 0) x = GPR(RA);
444 int shamt = RB & 31 if is32b else 63
445 for i in 0 to (6-is32b)
447 if (shamt & step) x = dorow(imm, x, step, is32b)
452 A variant may specify different LUT-pairs per row,
453 using one byte of RB for each. If it is desired that
454 a particular row-crossover shall not be applied it is
455 a simple matter to set the appropriate LUT-pair in RB
456 to effect an identity transform for that row (`0b11001010`).
459 uint64_t grevlutr(uint64_t RA, uint64_t RB, bool iv, bool is32b)
461 uint64_t x = 0x5555_5555_5555_5555;
462 if (RA != 0) x = GPR(RA);
464 for i in 0 to (6-is32b)
466 imm = (RB>>(i*8))&0xff
467 x = dorow(imm, x, step, is32b)
473 | 0.5|6.10|11.15|16.20 |21..28 | 29.30|31| name | Form |
474 | -- | -- | --- | --- | ----- | -----|--| ------ | ----- |
475 | NN | RT | RA | s0-4 | im0-7 | 1 iv |s5| grevlogi | |
476 | NN | RT | RA | RB | im0-7 | 01 |0 | grevlog | |
478 An equivalent to `grevlogw` may be synthesised by setting the
479 appropriate bits in RB to set the top half of RT to zero.
480 Thus an explicit grevlogw instruction is not necessary.
484 based on RV bitmanip.
486 RA contains a vector of indices to select parts of RB to be
487 copied to RT. The immediate-variant allows up to an 8 bit
488 pattern (repeated) to be targetted at different parts of RT.
490 xperm shares some similarity with one of the uses of bmator
491 in that xperm indices are binary addressing where bitmator
492 may be considered to be unary addressing.
495 uint_xlen_t xpermi(uint8_t imm8, uint_xlen_t RB, int sz_log2)
498 uint_xlen_t sz = 1LL << sz_log2;
499 uint_xlen_t mask = (1LL << sz) - 1;
500 uint_xlen_t RA = imm8 | imm8<<8 | ... | imm8<<56;
501 for (int i = 0; i < XLEN; i += sz) {
502 uint_xlen_t pos = ((RA >> i) & mask) << sz_log2;
504 r |= ((RB >> pos) & mask) << i;
508 uint_xlen_t xperm(uint_xlen_t RA, uint_xlen_t RB, int sz_log2)
511 uint_xlen_t sz = 1LL << sz_log2;
512 uint_xlen_t mask = (1LL << sz) - 1;
513 for (int i = 0; i < XLEN; i += sz) {
514 uint_xlen_t pos = ((RA >> i) & mask) << sz_log2;
516 r |= ((RB >> pos) & mask) << i;
520 uint_xlen_t xperm_n (uint_xlen_t RA, uint_xlen_t RB)
521 { return xperm(RA, RB, 2); }
522 uint_xlen_t xperm_b (uint_xlen_t RA, uint_xlen_t RB)
523 { return xperm(RA, RB, 3); }
524 uint_xlen_t xperm_h (uint_xlen_t RA, uint_xlen_t RB)
525 { return xperm(RA, RB, 4); }
526 uint_xlen_t xperm_w (uint_xlen_t RA, uint_xlen_t RB)
527 { return xperm(RA, RB, 5); }
532 bmatflip and bmatxor is found in the Cray XMT, and in x86 is known
533 as GF2P8AFFINEQB. uses:
535 * <https://gist.github.com/animetosho/d3ca95da2131b5813e16b5bb1b137ca0>
536 * SM4, Reed Solomon, RAID6
537 <https://stackoverflow.com/questions/59124720/what-are-the-avx-512-galois-field-related-instructions-for>
538 * Vector bit-reverse <https://reviews.llvm.org/D91515?id=305411>
539 * Affine Inverse <https://github.com/HJLebbink/asm-dude/wiki/GF2P8AFFINEINVQB>
541 | 0.5|6.10|11.15|16.20| 21 | 22.23 | 24....30 |31| name | Form |
542 | -- | -- | --- | --- | -- | ----- | -------- |--| ---- | ------- |
543 | NN | RS | RA |im04 | im5| 1 1 | im67 00 110 |Rc| bmatxori | TODO |
547 uint64_t bmatflip(uint64_t RA)
556 uint64_t bmatxori(uint64_t RS, uint64_t RA, uint8_t imm) {
558 uint64_t RAt = bmatflip(RA);
559 uint8_t u[8]; // rows of RS
560 uint8_t v[8]; // cols of RA
561 for (int i = 0; i < 8; i++) {
566 for (int i = 0; i < 64; i++) {
567 bit = (imm >> (i%8)) & 1;
568 bit ^= pcnt(u[i / 8] & v[i % 8]) & 1;
574 uint64_t bmatxor(uint64_t RA, uint64_t RB) {
575 return bmatxori(RA, RB, 0xff)
578 uint64_t bmator(uint64_t RA, uint64_t RB) {
580 uint64_t RBt = bmatflip(RB);
581 uint8_t u[8]; // rows of RA
582 uint8_t v[8]; // cols of RB
583 for (int i = 0; i < 8; i++) {
588 for (int i = 0; i < 64; i++) {
589 if ((u[i / 8] & v[i % 8]) != 0)
595 uint64_t bmatand(uint64_t RA, uint64_t RB) {
597 uint64_t RBt = bmatflip(RB);
598 uint8_t u[8]; // rows of RA
599 uint8_t v[8]; // cols of RB
600 for (int i = 0; i < 8; i++) {
605 for (int i = 0; i < 64; i++) {
606 if ((u[i / 8] & v[i % 8]) == 0xff)
613 # Introduction to Carry-less and GF arithmetic
615 * obligatory xkcd <https://xkcd.com/2595/>
617 There are three completely separate types of Galois-Field-based arithmetic
618 that we implement which are not well explained even in introductory
619 literature. A slightly oversimplified explanation is followed by more
620 accurate descriptions:
622 * `GF(2)` carry-less binary arithmetic. this is not actually a Galois Field,
623 but is accidentally referred to as GF(2) - see below as to why.
624 * `GF(p)` modulo arithmetic with a Prime number, these are "proper"
626 * `GF(2^N)` carry-less binary arithmetic with two limits: modulo a power-of-2
627 (2^N) and a second "reducing" polynomial (similar to a prime number), these
628 are said to be GF(2^N) arithmetic.
630 further detailed and more precise explanations are provided below
632 * **Polynomials with coefficients in `GF(2)`**
633 (aka. Carry-less arithmetic -- the `cl*` instructions).
634 This isn't actually a Galois Field, but its coefficients are. This is
635 basically binary integer addition, subtraction, and multiplication like
636 usual, except that carries aren't propagated at all, effectively turning
637 both addition and subtraction into the bitwise xor operation. Division and
638 remainder are defined to match how addition and multiplication works.
639 * **Galois Fields with a prime size**
640 (aka. `GF(p)` or Prime Galois Fields -- the `gfp*` instructions).
641 This is basically just the integers mod `p`.
642 * **Galois Fields with a power-of-a-prime size**
643 (aka. `GF(p^n)` or `GF(q)` where `q == p^n` for prime `p` and
645 We only implement these for `p == 2`, called Binary Galois Fields
646 (`GF(2^n)` -- the `gfb*` instructions).
647 For any prime `p`, `GF(p^n)` is implemented as polynomials with
648 coefficients in `GF(p)` and degree `< n`, where the polynomials are the
649 remainders of dividing by a specificly chosen polynomial in `GF(p)` called
650 the Reducing Polynomial (we will denote that by `red_poly`). The Reducing
651 Polynomial must be an irreducable polynomial (like primes, but for
652 polynomials), as well as have degree `n`. All `GF(p^n)` for the same `p`
653 and `n` are isomorphic to each other -- the choice of `red_poly` doesn't
654 affect `GF(p^n)`'s mathematical shape, all that changes is the specific
655 polynomials used to implement `GF(p^n)`.
657 Many implementations and much of the literature do not make a clear
658 distinction between these three categories, which makes it confusing
659 to understand what their purpose and value is.
661 * carry-less multiply is extremely common and is used for the ubiquitous
662 CRC32 algorithm. [TODO add many others, helps justify to ISA WG]
663 * GF(2^N) forms the basis of Rijndael (the current AES standard) and
664 has significant uses throughout cryptography
665 * GF(p) is the basis again of a significant quantity of algorithms
666 (TODO, list them, jacob knows what they are), even though the
667 modulo is limited to be below 64-bit (size of a scalar int)
669 # Instructions for Carry-less Operations
671 aka. Polynomials with coefficients in `GF(2)`
673 Carry-less addition/subtraction is simply XOR, so a `cladd`
674 instruction is not provided since the `xor[i]` instruction can be used instead.
676 These are operations on polynomials with coefficients in `GF(2)`, with the
677 polynomial's coefficients packed into integers with the following algorithm:
680 [[!inline pagenames="gf_reference/pack_poly.py" raw="yes"]]
683 ## Carry-less Multiply Instructions
686 see <https://en.wikipedia.org/wiki/CLMUL_instruction_set> and
687 <https://www.felixcloutier.com/x86/pclmulqdq> and
688 <https://en.m.wikipedia.org/wiki/Carry-less_product>
690 They are worth adding as their own non-overwrite operations
691 (in the same pipeline).
693 ### `clmul` Carry-less Multiply
696 [[!inline pagenames="gf_reference/clmul.py" raw="yes"]]
699 ### `clmulh` Carry-less Multiply High
702 [[!inline pagenames="gf_reference/clmulh.py" raw="yes"]]
705 ### `clmulr` Carry-less Multiply (Reversed)
707 Useful for CRCs. Equivalent to bit-reversing the result of `clmul` on
711 [[!inline pagenames="gf_reference/clmulr.py" raw="yes"]]
714 ## `clmadd` Carry-less Multiply-Add
717 clmadd RT, RA, RB, RC
721 (RT) = clmul((RA), (RB)) ^ (RC)
724 ## `cltmadd` Twin Carry-less Multiply-Add (for FFTs)
726 Used in combination with SV FFT REMAP to perform a full Discrete Fourier
727 Transform of Polynomials over GF(2) in-place. Possible by having 3-in 2-out,
728 to avoid the need for a temp register. RS is written to as well as RT.
730 Note: Polynomials over GF(2) are a Ring rather than a Field, so, because the
731 definition of the Inverse Discrete Fourier Transform involves calculating a
732 multiplicative inverse, which may not exist in every Ring, therefore the
733 Inverse Discrete Fourier Transform may not exist. (AFAICT the number of inputs
734 to the IDFT must be odd for the IDFT to be defined for Polynomials over GF(2).
735 TODO: check with someone who knows for sure if that's correct.)
738 cltmadd RT, RA, RB, RC
741 TODO: add link to explanation for where `RS` comes from.
746 # read all inputs before writing to any outputs in case
747 # an input overlaps with an output register.
748 (RT) = clmul(a, (RB)) ^ c
752 ## `cldivrem` Carry-less Division and Remainder
754 `cldivrem` isn't an actual instruction, but is just used in the pseudo-code
755 for other instructions.
758 [[!inline pagenames="gf_reference/cldivrem.py" raw="yes"]]
761 ## `cldiv` Carry-less Division
770 q, r = cldivrem(n, d, width=XLEN)
774 ## `clrem` Carry-less Remainder
783 q, r = cldivrem(n, d, width=XLEN)
787 # Instructions for Binary Galois Fields `GF(2^m)`
791 * <https://courses.csail.mit.edu/6.857/2016/files/ffield.py>
792 * <https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture7.pdf>
793 * <https://foss.heptapod.net/math/libgf2/-/blob/branch/default/src/libgf2/gf2.py>
795 Binary Galois Field addition/subtraction is simply XOR, so a `gfbadd`
796 instruction is not provided since the `xor[i]` instruction can be used instead.
798 ## `GFBREDPOLY` SPR -- Reducing Polynomial
800 In order to save registers and to make operations orthogonal with standard
801 arithmetic, the reducing polynomial is stored in a dedicated SPR `GFBREDPOLY`.
802 This also allows hardware to pre-compute useful parameters (such as the
803 degree, or look-up tables) based on the reducing polynomial, and store them
804 alongside the SPR in hidden registers, only recomputing them whenever the SPR
805 is written to, rather than having to recompute those values for every
808 Because Galois Fields require the reducing polynomial to be an irreducible
809 polynomial, that guarantees that any polynomial of `degree > 1` must have
810 the LSB set, since otherwise it would be divisible by the polynomial `x`,
811 making it reducible, making whatever we're working on no longer a Field.
812 Therefore, we can reuse the LSB to indicate `degree == XLEN`.
815 [[!inline pagenames="gf_reference/decode_reducing_polynomial.py" raw="yes"]]
818 ## `gfbredpoly` -- Set the Reducing Polynomial SPR `GFBREDPOLY`
820 unless this is an immediate op, `mtspr` is completely sufficient.
823 [[!inline pagenames="gf_reference/gfbredpoly.py" raw="yes"]]
826 ## `gfbmul` -- Binary Galois Field `GF(2^m)` Multiplication
833 [[!inline pagenames="gf_reference/gfbmul.py" raw="yes"]]
836 ## `gfbmadd` -- Binary Galois Field `GF(2^m)` Multiply-Add
839 gfbmadd RT, RA, RB, RC
843 [[!inline pagenames="gf_reference/gfbmadd.py" raw="yes"]]
846 ## `gfbtmadd` -- Binary Galois Field `GF(2^m)` Twin Multiply-Add (for FFT)
848 Used in combination with SV FFT REMAP to perform a full `GF(2^m)` Discrete
849 Fourier Transform in-place. Possible by having 3-in 2-out, to avoid the need
850 for a temp register. RS is written to as well as RT.
853 gfbtmadd RT, RA, RB, RC
856 TODO: add link to explanation for where `RS` comes from.
861 # read all inputs before writing to any outputs in case
862 # an input overlaps with an output register.
863 (RT) = gfbmadd(a, (RB), c)
864 # use gfbmadd again since it reduces the result
865 (RS) = gfbmadd(a, 1, c) # "a * 1 + c"
868 ## `gfbinv` -- Binary Galois Field `GF(2^m)` Inverse
875 [[!inline pagenames="gf_reference/gfbinv.py" raw="yes"]]
878 # Instructions for Prime Galois Fields `GF(p)`
880 ## `GFPRIME` SPR -- Prime Modulus For `gfp*` Instructions
882 ## `gfpadd` Prime Galois Field `GF(p)` Addition
889 [[!inline pagenames="gf_reference/gfpadd.py" raw="yes"]]
892 the addition happens on infinite-precision integers
894 ## `gfpsub` Prime Galois Field `GF(p)` Subtraction
901 [[!inline pagenames="gf_reference/gfpsub.py" raw="yes"]]
904 the subtraction happens on infinite-precision integers
906 ## `gfpmul` Prime Galois Field `GF(p)` Multiplication
913 [[!inline pagenames="gf_reference/gfpmul.py" raw="yes"]]
916 the multiplication happens on infinite-precision integers
918 ## `gfpinv` Prime Galois Field `GF(p)` Invert
924 Some potential hardware implementations are found in:
925 <https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.5233&rep=rep1&type=pdf>
928 [[!inline pagenames="gf_reference/gfpinv.py" raw="yes"]]
931 ## `gfpmadd` Prime Galois Field `GF(p)` Multiply-Add
934 gfpmadd RT, RA, RB, RC
938 [[!inline pagenames="gf_reference/gfpmadd.py" raw="yes"]]
941 the multiplication and addition happens on infinite-precision integers
943 ## `gfpmsub` Prime Galois Field `GF(p)` Multiply-Subtract
946 gfpmsub RT, RA, RB, RC
950 [[!inline pagenames="gf_reference/gfpmsub.py" raw="yes"]]
953 the multiplication and subtraction happens on infinite-precision integers
955 ## `gfpmsubr` Prime Galois Field `GF(p)` Multiply-Subtract-Reversed
958 gfpmsubr RT, RA, RB, RC
962 [[!inline pagenames="gf_reference/gfpmsubr.py" raw="yes"]]
965 the multiplication and subtraction happens on infinite-precision integers
967 ## `gfpmaddsubr` Prime Galois Field `GF(p)` Multiply-Add and Multiply-Sub-Reversed (for FFT)
969 Used in combination with SV FFT REMAP to perform
970 a full Number-Theoretic-Transform in-place. Possible by having 3-in 2-out,
971 to avoid the need for a temp register. RS is written
975 gfpmaddsubr RT, RA, RB, RC
978 TODO: add link to explanation for where `RS` comes from.
984 # read all inputs before writing to any outputs in case
985 # an input overlaps with an output register.
986 (RT) = gfpmadd(factor1, factor2, term)
987 (RS) = gfpmsubr(factor1, factor2, term)
990 # Already in POWER ISA or subsumed
992 Lists operations either included as part of
993 other bitmanip operations, or are already in
998 based on RV bitmanip, covered by ternlog bitops
1001 uint_xlen_t cmix(uint_xlen_t RA, uint_xlen_t RB, uint_xlen_t RC) {
1002 return (RA & RB) | (RC & ~RB);
1006 ## count leading/trailing zeros with mask
1012 do i = 0 to 63 if((RB)i=1) then do
1013 if((RS)i=1) then break end end count ← count + 1
1019 pdepd VRT,VRA,VRB, identical to RV bitmamip bdep, found already in v3.1 p106
1022 if VSR[VRB+32].dword[i].bit[63-m]=1 then do
1023 result = VSR[VRA+32].dword[i].bit[63-k]
1024 VSR[VRT+32].dword[i].bit[63-m] = result
1030 uint_xlen_t bdep(uint_xlen_t RA, uint_xlen_t RB)
1033 for (int i = 0, j = 0; i < XLEN; i++)
1034 if ((RB >> i) & 1) {
1036 r |= uint_xlen_t(1) << i;
1046 other way round: identical to RV bext: pextd, found in v3.1 p196
1049 uint_xlen_t bext(uint_xlen_t RA, uint_xlen_t RB)
1052 for (int i = 0, j = 0; i < XLEN; i++)
1053 if ((RB >> i) & 1) {
1055 r |= uint_xlen_t(1) << j;
1064 found in v3.1 p106 so not to be added here
1074 if((RB)63-i==1) then do
1075 result63-ptr1 = (RS)63-i
1081 ## bit to byte permute
1083 similar to matrix permute in RV bitmanip, which has XOR and OR variants,
1084 these perform a transpose (bmatflip).
1085 TODO this looks VSX is there a scalar variant
1090 b = VSR[VRB+32].dword[i].byte[k].bit[j]
1091 VSR[VRT+32].dword[i].byte[j].bit[k] = b
1095 superceded by grevlut
1097 based on RV bitmanip, this is also known as a butterfly network. however
1098 where a butterfly network allows setting of every crossbar setting in
1099 every row and every column, generalised-reverse (grev) only allows
1100 a per-row decision: every entry in the same row must either switch or
1103 <img src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/8c/Butterfly_Network.jpg/474px-Butterfly_Network.jpg" />
1106 uint64_t grev64(uint64_t RA, uint64_t RB)
1109 int shamt = RB & 63;
1110 if (shamt & 1) x = ((x & 0x5555555555555555LL) << 1) |
1111 ((x & 0xAAAAAAAAAAAAAAAALL) >> 1);
1112 if (shamt & 2) x = ((x & 0x3333333333333333LL) << 2) |
1113 ((x & 0xCCCCCCCCCCCCCCCCLL) >> 2);
1114 if (shamt & 4) x = ((x & 0x0F0F0F0F0F0F0F0FLL) << 4) |
1115 ((x & 0xF0F0F0F0F0F0F0F0LL) >> 4);
1116 if (shamt & 8) x = ((x & 0x00FF00FF00FF00FFLL) << 8) |
1117 ((x & 0xFF00FF00FF00FF00LL) >> 8);
1118 if (shamt & 16) x = ((x & 0x0000FFFF0000FFFFLL) << 16) |
1119 ((x & 0xFFFF0000FFFF0000LL) >> 16);
1120 if (shamt & 32) x = ((x & 0x00000000FFFFFFFFLL) << 32) |
1121 ((x & 0xFFFFFFFF00000000LL) >> 32);
1129 based on RV bitmanip, gorc is superceded by grevlut
1132 uint32_t gorc32(uint32_t RA, uint32_t RB)
1135 int shamt = RB & 31;
1136 if (shamt & 1) x |= ((x & 0x55555555) << 1) | ((x & 0xAAAAAAAA) >> 1);
1137 if (shamt & 2) x |= ((x & 0x33333333) << 2) | ((x & 0xCCCCCCCC) >> 2);
1138 if (shamt & 4) x |= ((x & 0x0F0F0F0F) << 4) | ((x & 0xF0F0F0F0) >> 4);
1139 if (shamt & 8) x |= ((x & 0x00FF00FF) << 8) | ((x & 0xFF00FF00) >> 8);
1140 if (shamt & 16) x |= ((x & 0x0000FFFF) << 16) | ((x & 0xFFFF0000) >> 16);
1143 uint64_t gorc64(uint64_t RA, uint64_t RB)
1146 int shamt = RB & 63;
1147 if (shamt & 1) x |= ((x & 0x5555555555555555LL) << 1) |
1148 ((x & 0xAAAAAAAAAAAAAAAALL) >> 1);
1149 if (shamt & 2) x |= ((x & 0x3333333333333333LL) << 2) |
1150 ((x & 0xCCCCCCCCCCCCCCCCLL) >> 2);
1151 if (shamt & 4) x |= ((x & 0x0F0F0F0F0F0F0F0FLL) << 4) |
1152 ((x & 0xF0F0F0F0F0F0F0F0LL) >> 4);
1153 if (shamt & 8) x |= ((x & 0x00FF00FF00FF00FFLL) << 8) |
1154 ((x & 0xFF00FF00FF00FF00LL) >> 8);
1155 if (shamt & 16) x |= ((x & 0x0000FFFF0000FFFFLL) << 16) |
1156 ((x & 0xFFFF0000FFFF0000LL) >> 16);
1157 if (shamt & 32) x |= ((x & 0x00000000FFFFFFFFLL) << 32) |
1158 ((x & 0xFFFFFFFF00000000LL) >> 32);
1167 see [[bitmanip/appendix]]