Distinguish instructions which have once been valid (OBSOLETE) from
those that never saw the light of day (NEVER). Futhermore, flag
instructions which devolve to an architectural noop from those with
undefined behavior and possibly recycled opcodes.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Clean up some perl warnings, some of which were legitimate (apparently
undef doesn't actually take a list of arguments, a common enough
mistake that it is mentioned in the man page!, and a list of variables
after "my" can be cantankerous), and some of which were nuisance but
were easy enough to clean up.
Maybe this can resolve the problems with very old version of Perl?
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This allows the K instructions to be specified without a size suffix
as long as the operands are sized; this matches the way most other x86
instructions work. As this is not the syntax specified in the SDM,
don't use it for disassembly.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The flags massaging in insns.pl could end up with things like double
commas in some pathological cases, which would make insns_flag_index()
very unhappy due to the appearance of an empty argument. Fix this by
processing the flags as a list already in insns.pl.
Be more explicit and consistent in error messages.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add comments to iflag.c so a human user can have any hope of
figuring out what a particular bitmask actually means.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add file missing from commit 418138c8f2:
iflags: move definitions to a separate file; auto-generate more
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Move the definitions to a separate file, in order to separate code
from data better.
We can auto-generate more information about the instruction flags, so
let's do so.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
AMD documents this instruction with an rax operand. The error behavior
implies this is an address-size-sensitive instruction. Add support for
specifying the explicit operand, but consistent with normal ndisasm
behavior, don't disassemble the implicit operand.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Support the +n syntax for multiple contiguous registers, and emit it
in the output from ndisasm as well.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
New instructions which do four full iterations of a data-reduction
operation (FMA, dot product.)
Bug report: https://bugzilla.nasm.us/show_bug.cgi?id=3392492
Reported-by: ff_ff <qqqqqqqqqfffffffff@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add PTWRITE instruction. It is worth noting that we should
be able to do "ptwrite [eax]" in 32-bit mode, but the instruction
selector doesn't currently handle that well in a way that doesn't make
64-bit mode very confusing.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add instructions from the Intel Instruction Set Extensions and Future
Features Programming Reference, document 319433-034, May 2018.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make it possible to generate variants of RET(F) with explicit operand
size specified without having to use o16/o32/o64.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Automatically assign values to the instruction flags; we ended up with
a case where pushing flags into the next dword caused comparison
failures due to other places in the code explicitly comparing
field[3].
This creates necessary defines for this not to happen; it also cleans
up a fair bit of the iflag code.
This resolves BR 3392454.
Reported-by: Thomasz Kantecki <tomasz.kantecki@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
We could generate the MRI version (SSE 4.1) instead of the RMI
(SSE 2) version of these instructions if a 64-bit register was given
as the destination.
Reported-by: Vasiliy Olekhov <olekhov@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
We don't need to sort opcodes anymore, since we are using an O(1) hash
and not binary search. Instead, sort them in the order they first
appear in insns.dat; this lets us move all the pseudo-ops to a
contiguous range at the start of the file, for more efficient
handling.
Change the functions that process pseudo-ops accordingly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Compactify the instruction list in the documentation to have fewer
margin violations, and fix some of the headings (;#).
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The fvm: annotation to generate the correct EVEX compressed
displacements had inadvertently gotten dropped from a handful of
instructions in checkin c33d95fde9:
BR 3392370: {z} decorator allowed on MOVDQ* memory operands
Put them back, and verify they work.
Reported-by: Henrik <henrik@gramner.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
insns-iflags.ph is included from another Perl script, so rename it .ph
(Perl header). Add missing dependency to the main Makefile.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The 2-operand form was inherently unsafe. Use the 3-operand form
instead, which guarantees that arbitrary filenames are supported.
This also means we can remove a few instances of sysopen() which was
used for exactly this reason, however, at least in theory sysopen()
isn't portable.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The spec says very clearly the {z} decorator is allowed on memory
operands for the MOVDQ* instructions. Remove special cases from the
code to disallow this case, which had the unfortunate effect of
generating a very uninformative error message.
Reported-by: Agner <agner@agner.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The UD0 and UD1 opcodes are now officially documented, with UD1
officially documented to take a modr/m. Still permit the "UD2B" and
argument-less aliases, but not as preferred.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The constant arrays in get_disp8N() should be static; otherwise the
compiler has to manifest them on the stack for every execution which
makes no sense at all.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>