Permuting Bits with GF2P8AFFINEQB

So this is perhaps more accurately denoted as:

* (A[0] * x + A[1] * x + ... A[7] * x + B).

If we normalize everything to 8-bit values. This is a far more powerful operation than I initially described. Where * is this pseudo-multiply (bitshift and xor) operation and + is XOR.

VGF2P8AFFINEQB zmm1{k1}{z}, zmm2, zmm3/m512/m64bcst, imm8

So there are 3x AVX512 registers + 1x 8-bit immediate.

zmm1 seems to be the output register, the 64x 8-bit results.

zmm2 seems to be the "64x parallel x" in Ax + b.

zmm3 seems to be a 8x parallel A-matrix. I'm not sure how these 8x A-matrices line up to the final result, but perhaps 8-at-a-time is the logical conclusion. (outputs values#0-7 use A[0] matrix. Output#8-15 uses A[1] matrix?)

imm8 seems to be "b" in the Ax + b formula, and is shared with all operations.

--------

EDIT: I think I get it now. Edited this post with my latest understanding.

https://www.intel.com/content/www/us/en/docs/intrinsics-guid...

Intel's documentation is claiming 0.5 CPI, or a bandwidth of 2x of these operations per clock tick.

I mean, forget about bit-shuffling or permuting. I feel like with the right configuration, you can operate 512-bits of CRC32 calculations in parallel, maybe in like 3 or 4 instructions (or ~2 clock ticks) or something incredibly fast.

> this ends up quite limiting if you want different matrices, so most of the uses are ones where the matrix is the same for all elements

Elliptical Curves is the obvious use case.

CRC is one immediate use where all the matricies are the same (and linear in the GF-field), albeit the reduction needs to be done "somehow" but that can be figured out in a later operation... probably...

AES encryption is operated over 4x sets of GF(2^8). I know that AES is already got its own instruction but a full software implementation of the GF-operations behind AES might be possible with this.

--------------

I dunno, there's a lot of things I see already as immediately applicable where the "A" matrix is nearly constant across all elements. And for those where A isn't constant, pipelined operation is obvious.

8x different "A" matrixies means that we can build a "pipeline" where we can AVX512-shift the bytes down by 8 as well each clock tick, and build an 8x-deep pipeline and apply those 8x A matricies in parallel while consuming 64-bytes per clock-tick, while performing 512-bit worth of operation per clock tick (no, 1024-bits because Intel chips support 2x such operations per clock tick).

Pipelining, full parallelization, etc. etc. So many architectures are possible with this spec. IMO, it shows that Intel knows what they're doing with these intrinsic, and I think this is something now GPU can accomplish yet. Truly an advantage to Intel chips only.

Very nice instruction. The practical benefits though (Intel-only, exceptionally arcane with very few programmers who can work with, etc. etc.) may make it a dead instruction though. But I'm sure some wizard out there is going to do something cool with this instruction over the next 5 years. (It'd probably take weeks of practice on some practice problem just to learn how to use this instruction correctly, lol)

I appreciate the uops.info table. I've never known about that site, so I'll save that off now. Very nicely presented latency/throughput stats.

-----------

EDIT: Looks like https://www.felixcloutier.com/x86/gf2p8mulb also exists. The 0b1'0001'1011 polynomial / x^8 + x^4+x^3+x+1 intrigues me, anyone have any idea why this particular GF-polynomial was chosen?

EDIT2: Looks like its related to AES somehow (https://crypto.stackexchange.com/questions/51848/why-is-x8-x...). The CPU-chip already has AES-instructions hard coded for modern TLS reasons (and AES-acceleration is going to be in every modern chip). So I'm thinking that these multiplication routines might be "sharing the fundamental units" of the Intel CPU, and Intel is wondering if anyone out there can make due with the individual steps of Rinjadel/AES in other applications.