This is a WIP checkpoint; not all tests pass yet.
More matching changes, and hopefully something much closer to what
really is desired now. The number of required patterns is now much
smaller.
However, a lot of *changes* are needed to the patterns.
Since some patterns are repeated all over the place, clean up the
x86/addflags.pl script and make it able to generate macro-based
common patterns; first use being the patterns for the "basic 8"
arithmetic patterns.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Work through a number of changes toward making matching a lot saner,
both to reduce the number of patterns to generate for APX but also to
make a number of code patterns simpler.
This replaces a fair number of byte codes.
Improve a number of error messages, especially related to overflows.
Move process_insn() from nasm.c to assemble.c, as it really is the
primary entry point to the assembler module.
Reorder some prefixes. In particular, F2/F3 override 66 when used as a
mandatory prefix, so it makes more sense for them to be closer to the
opcode.
Move a lot more information into struct insn. It is better to have it
in one place; memory consumption is not an issue because struct insn
is transient information.
Get rid of "optimization levels" and replace it with a mask of
flags. That was already halfway done; complete the job.
Replace seg:offset in struct out_data with a struct location. It would
be better to extend this to more places, too.
The ARx and SMx flags are now explicit bitmasks, instead of having a
couple of hard-coded ranges.
Add __func__ to assert or panic messages.
Because of prefix and message changes, a number of travis tests had to
be audited and updated.
Fix a number of instruction patterns which had .128 when they ought to
be .lig. This is no longer a minor issue with the disassembler: for
AVX10, the pattern vector length determines how SAE/RC are encoded,
and there is no valid 128-bit encoding. However, with .lig the 512-bit
encoding can be used.
Separate "o64nw" into two pieces: opsize 64 and "nw" = "REX.w not necessary". The
latter can be included in non-64-bit patterns. "o64" still set REX.W
since that is still the common thing.
New "osz" bytecode: emit an OSP *or* REX.W depending on the current
mode and operand size. Useful for special cases like "nop" where "o64
nop" probably wants to be encoded as "48 90".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add MOVSX[D] -> CBW/CWDE/CDQE optimization patterns when the suitable
form of the AX register are referenced.
Add MOVZX reg64,rm32 pattern which converts to a 32-bit MOV.
Add MOVZXD reg64,rm32 alias pattern for consistency.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For the instructions ending in -x because they don't modify the flags,
also accept {nf}. Add 2-operand relaxed versions like for most other
instructions, too.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make sure to get the right type for the disassembly tables. This is
now a fixed-depth tree, so there is no reason to use union types or
anything along those lines.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change the generation of tables for disassembly to be map-based. This
also makes the code a bit more regular.
This is the first step at catching up with APX support in the
disassembler.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
These are mostly structured. Leave this as an explicit processing
step, at least until the correctness of these flags have been fully
verified; perhaps after that as well.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Merge a bunch of common code in the handling of modr/m
generation. Make the handing of compressed disp8 simpler and more
transparent by exporting a the shift factor for the compressed
immediate in ea_data. For the case of no compression, the shift factor
is simply 0; there is no need to distinguish "compressed" from
"uncompressed".
The tidied up version of the disp8 code is simple enough that it makes
more sense to inline it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The {nf} and {zu} prefixes (or suffixes) can be used on a number of
instructions without actually change the encodings (either they don't
touch the flags at all, or they write a 32- or 64-bit register
already.)
Make this a bit more flexible, by adding an FL instruction flag for
the instructions which actually touch the flags, and a ZU instruction
flag for the instructions which zero the upper half.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For the instruction space that are explicitly excluded by REX2, add
NOAPX tags. This was done with an automated script.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Implement the JMPABS instruction, which can also be specified as JMP
ABS for consistency. Since ABS is already a keyword, this does not
pollute the namespace.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
EVEX encoding is really messy, with the 4th register bit in one of
several places depending on which type of register it is. It seems to
work now.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
a
Support generating code for APX instruction and add support for the
{nf} prefix.
No disassembler support yet, and only a handful instructions encoded.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change the byte code format and the byte code compiler to be able to
generate various kinds of APX-format instructions.
THE NEW BYTE CODES ARE NOT YET IMPLEMENTED IN THE ASSEMBLER OR
DISASSEMBLER.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
{dfv=} is basically a constant (immediate). Treat it as such during
parsing, except that if "naked" (not in an expression), it has special
matching properties and does not need a terminal comma.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change the handling of {dfv=} to a more general "braced constant"
expression, to be tagged with an instruction flag to make sure they
match the instruction in question.
This really ought to be an operand flag, but the opflags are precious;
as the CCMP/CTEST instructions can also take an immediate it probably
is necessary to invent a "special immediate" operand type that can
fold these together.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The {dfv=} prefix sequences for the CCMP and CTEST instructions need
special handling in the parser. This means a fair bit of new magic in
the handler of the parser, but it just adds to the fun.
Try to make this as general as possible, so we can use it for other
things.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Doing the register range flags by hand is a bit more work than
necessary when dealing with APX, so auto-generate the flags for ranges
{0, 1-15, 16+} using 3 bits.
In theory we could handle even more automagically by splitting ranges
up further: the existing ranges are sets of {0, 1, 2, 3, 4-5, 6-7,
8-15, 16-31} which would require 7 bits, although it would remove most
of the subclass bits for registers; it would require separating the
subclass bits for EAs from the ones for registers (which might be a
good idea anyway...)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
At least three files (asm/assemble.c, disasm/disasm.c, and
x86/insns.pl) depend on the bytecode defintions. It makes a lot more
sense for them to live in an explicit documentation file in the x86/
directory.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Comment was missing a semicolon; fix to avoid unnecessary warning and
to make sure the documentation is generated correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for VEX-encoded SHA512-NI instructions.
Signed-off-by: Tomasz Kantecki <tomasz.kantecki@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Kind of embarrassing... I had not implemented the FRED instruction,
despite personally being one of the architects of FRED ;)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"LOCK XCHG reg,mem" would issue a warning for being unlockable, which
is incorrect. In this case the RM encoding is simply an alias for the
MR encoding. Add a "LOCK1" bit to deal with that.
However, XCHG is *always* locked, so create a new warning to
explicitly flag a user-specified LOCK XCHG; default off.
Consider optimizing that prefix away in the future, but for now, let's
stick to the user-requested code sequence.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For VEX instructions created *after* the corresponding EVEX
instructions, we need the user to either explicitly declare them {vex}
or specifying "cpu latevex".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add vector instructions from the Intel Instruction Set Extensions
document, version 046, September 2022.
Still need to check for missing instructions that have already passed
through the ISE into the SDM.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Additional nonvector instructions from the Intel Instruction Set
Extensions document 319433-046 September 2022.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Instead of handling conditional instructions ad hoc, generate
individual instruction patterns as normal. This simplifies the code
and makes CMPccXADD support simpler (otherwise it would be necessary
to hack in the handling of a condition code in the middle of an
instruction.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for AVX512-FP16 instructions and the associated
handling. Allow "mapN" syntax as well as "mN" syntax to match the
documentation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The VCVTNEPS2BF16 instruction was incorrectly specified as
VCVTNE2S2BF16. Fortunately, the correct opcode for the latter was
specified first, so it would emit the correct result when that
instruction was specified.
Fixes: https://bugzilla.nasm.us/show_bug.cgi?id=3392821
Reported-by: Agner <agner@agner.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
