There aren't that many instructions which have been rmeoved from the
x86 architecture, but there is a handful. Flag those with an OBSOLETE
flag.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Allow specifying {vex3} or {vex2} (the latter is currently always
redundant, unless we end up with instructions at some point can be
specified with legacy prefixes or VEX) to select a specific encoding
of VEX-encoded instructions.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For checking the availability of {evex} prefix, AVX512 iflag
has been used. But this is a flag for an instruction set
not for an encoding scheme. And there are some AVX512 instructions
encoded with VEX prefix.
So a new instruction flag (IF_EVEX) is added for the instructions
which are actually encoded with EVEX prefix.
This flag is automatically added by insns.pl, so no need to add manually
in insns.dat.
Signed-off-by: Jin Kyu Song <jin.kyu.song@intel.com>
In order for iflag_cmp() to return an ordering that makes sense, we
need to scan from the most significant word downward. That way the
bits with the higher index consistently are the more significant.
This fixes the disassembler vendor selection algorithm. While we are
doing that, make that dependency more explicit in the comments.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Avoid using C99 constructs when not necessary. Don't hardcode the
number of words when we can autodiscover them.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Multi-dependencies don't work as expected, especially not across Make
versions, this is why we don't use them and read the instructions list
multiple times.
iflag.h has a lot of static content, so factor out the static content.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It been found that 64 bits for instruction flags is too small,
so instead we start using indirect addressing scheme to keep
instruction flags in bitvectors instead.
Using one bitvector per instruction template entry is wastefull
(especially if vector grow in future, at moment it's 128 bit length),
so we use indirect addressing, which is generated as follow
- read instruction flags from insns.dat
- flag sequence sorted and joined into one key string
- this key string become a hash index
- all hash entries are compacted into one array
- every instruction template uses array offset instead
of flags bitfield
Just for info, at moment we have 195 unique flags combination,
but since instruction template will use index as unsigned
integer, we can use a way more wider combination of flags
in future.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
