decoding x86/x86-64 instructions properly always seems like playing a game of Calvinball with an unbelievably formidable opponent because you'll be reading the ISA manual and it's always like:
VEX prefixes can be two-byte or three-byte. If you use the two-byte version, then the first byte needs to be 0xC5. If you use the three-byte version, then the first byte needs to be 0xC4. By the way, if the instruction happens to use the three-byte version, then the VEX.W bit can be set to indicate widening behavior.
and then it gets immediately followed up with:
By the way, sometimes VEX.W will be ignored lol
You see some other bits that also do this but not quite. They're all sort of the same, but ultimately have different edge cases. You begin questioning why you're doing this in the first place.
You find the VEX.vvvv bits that let the prefix encode a register value in the prefix. "Cool!". You read ahead and find out for compatibility reasons, the encoded register index needs to be inverted, so 0b1111 encodes XMM0 and 0b0000 encodes XMM15, etc. Uhh... ok.
You keep reading, surely that's the only weird thing about it. Every thing else will be Normal. Then, like the clown you are, you are soon proven completely wrong:
VEX.vvvv is not used by the instructions with one source (except certain shifts, see below)
As you slowly begin your descent into madness you see VEX.L where you get something like:
Yeah, if the VEX.L bit is set, then that means ur vector operation is 256-bit. If it's not set then it's a 128-bit operation.
and you finally think, "wow, finally, consistency", but then you read a little further and see:
By the way, VEX.L not being set can also indicate a scalar operation
and it's like this the entire bloody way through the ISA manual. Just non-stop mental wire-crossing with bits that are similar and sometimes interact with one another in the instruction and prefix encodings.