Created by: khuey
This is a long series. I've tried to break it up into discrete semi-meaningful pieces but it's still going to be tough going for whoever reviews it.
I originally thought that we could do this with flags but the {sae}/{er} stuff (coming later) threw a big wrench in that. Some instructions have as many as three variants:
- The normal EVEX.L/EVEX.LL controlled SIMD register/memory operand of appropriate size case.
- The broadcast variant, which has destinations controlled by the EVEX prefix but takes a fixed size memory operand.
- The {sae}/{er} variant which does not use the EVEX prefix at all but is instead a fixed size (the highest the instruction offers, but notably in some cases it is not a ZMM register e.g. any -SS instruction).
The latter two are distinguishable only by the modrm byte, not by anything in the EVEX prefix, so when we add {sae}/{er} support some of the entries added here will become lookups into mod_extensions.
Everything here is tested with API tests and I've also run the binutils test suite (not included in this PR, since it also requires {sae}/{er}) and verified that all of their cases produce output (whether they produce the correct output is not verified, but roundtripping the binutils cases through the decoder/encoder did find some issues).
Open questions:
- Should we rename
evex_W_extensionstoevex_WB_extensionsor something similar? - Should we apply the OPCODE_TWOBYTES stealing to VEX prefixed instructions too and reclaim a bit for them, even though we have no current use for them.