The mask is the selector picking elements from vector a and vector b. It seems rather limiting to have a fixed selector at comptime. It precludes a whole bunch of usages of dynamically generating a selector mask in runtime.
#Is there a reason that the fourth parameter 'mask' of @shuffle is a comptime?
rustic widget
soft abyss
It's because of the way the vector instructions work
terse gale
because most architectures that have shuffle require it as an immediate, not a register
soft abyss
The mask is encoded into the instruction itself
So it can't come from a runtime value (unless you do some horribly cursed self-modifying stuff, I guess)
lavish herald
x86 SSE3 with pshufb and arm neon with tbl/tbx do shuffles and take a runtime mask
soft abyss
it's less about "can it be done on some platforms" and more about "can it be done consistently on every platform we want to support"
rustic widget
ok, i see. it's directly translated to the SIMD opcode. i guess it's for fixed predetermined selectors.
lavish herald
it's less about "can it be done on *some* platforms" and more about "can it be d...
its a well known law that simd only matterns on sse, neon and maybe powerpc/wasm 
soft abyss
sure, and sse 1 and 2 don't support runtime masks :)
lavish herald
ah yea baseline is pentium4
rustic widget
i guess it becomes a problem of generating vector a and vector b dynamically to fit the constant selector pattern 'mask'.
soft abyss
ah yea baseline is pentium4
yes, but also zig supports i386, which can potentially have no sse at all
lavish herald
just dreaming of certain intrinsic support which compile-errors on unsupported platforms (i.e. gather/scatter). But in this case, thats the job of a library
rustic widget
this problem aside, zig has the best simd support i've seen so far. the vector abstraction in the language really simplifies the simd usage. miles ahead of other languages.