#Permute unit definition code

I'd love to see a less hand-wavy answer from someone with hardware design experience. They could implement it with multiple stages of shuffling (rather than a single 32:1 stage), since lane-crossing shuffles get a 3-cycle time budget to get their work done. I'm pretty sure that thirty two 32:1 muxers are a lot more expensive than eight 8:1 muxers, even if the 8:1 muxers are 4x wider. Skylake Xeon will only bring vpermi2w and larger element sizes (AVX512F + AVX512BW).

#Permute unit definition code

(Part of that is that I think these days a lot of code that can take advantage of brand new instruction sets is written to run on known servers, instead of runtime dispatching for use on client machines).Īccording to Wikipedia, AVX512VBMI isn't coming until Cannonlake, but then we will have vpermi2b, which does 64 parallel table lookups from a 128B table (2 zmm vectors)). AVX512F takes a lot of die area / transistors to implement, so much that Intel decided not to even implement it in retail desktop CPUs for a couple generations. Maybe they realized how much it sucked to not have this, and decided to do it anyway. They decided to implement it for AVX512VBMI, though, with larger element sizes available in AVX512BW and AVX512F. Like, really a lot, since the field that represents combinations of prefixes isn't a bit-field, it's an integer with most of the values unused. It would clearly be very useful, and the only reason it doesn't exist is that the implementation cost must outweigh the significant benefit.Ĭoding space issues are unlikely the VEX coding space provides a LOT of room. I'm 99% sure the main factor is transistor cost of implementation.

This makes the instruction an order of magnitude more flexible than the earlier variants that take an immediate shuffle mask, in the same way that add is more flexible than inc or a variable shift is more flexible than an immediate shift.ģThe older instructions are occasionally useful if they have a shorter encoding, or avoid loading a mask from memory, but functionally they are superseded. Is the operation intrinsically harder to implement in hardware? Are there encoding restrictions forcing its omission?ġBy selectable at runtime, I mean that the mask that defines the shuffling behavior comes from a register. I have no doubt that Intel is aware of the wide and heavy use of PSHUFB, so the question naturally arises as to why the byte variant was omitted in AVX2. There doesn't even seem to be a good way to emulate this instruction, whereas you can easily emulate the larger-width shuffles with smaller-width ones (often, it's even free: you just need a different mask). The VPERM instructions are able to do cross shuffle (in fact, 'perm' and 'shuf' seem to be synonyms in the instruction mnemonics?) - but the 8 and 16-bit versions were omitted?

Unfortunately, PSHUFB wasn't extended to be cross-lane in AVX2, so it is restricted to within-lane behavior. Furthermore, it can also be used to do 16 parallel 4-bit -> 8-bit table lookups 2. It can do any possible permutation, broadcast or byte-wise shuffle. Or, for that matter, where is VPERMW, for 16-bit elements? Having dabbled in x86 assembly for some time, it is pretty clear that the SSE PSHUFB instruction is pretty much among the most useful instructions of all time. So where is VPERMB? I.e., the same instruction, but working on byte-sized elements. Functionally, that obsoletes a whole slew of existing old unpack, broadcast, permute, shuffle and shift instructions 3. Take VPERMD: it allows you to totally arbitrarily broadcast/shuffle/permute from one 256-bit long vector of 32-bit values into another, with the permutation selectable at runtime 1. For example, it has plenty of instructions which are pretty much strictly more powerful than their precursors.