More matching and macrofication work.
Improve some error and warning messages.
Update some travis tests for better messages and added optimizations.
Fix duplicated warning messages for the same out-of-range value
problem.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
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>
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>
Require the second colon before the grouped parameter count; otherwise
the syntax is ambiguous since an expression can start with (.
Update/complete the documentation and the examples.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the %map() function which can apply arguments to a macro from a
list.
Allow the user to specify the desired radix for an evaluated
parameter. It doesn't make any direct difference, but can be nice for
debugging or turning into strings.
As part of this, split expand_one_smacro() into two parts: parameter
parsing and macro expansion. This is a very straightforward splitting
of two mostly unrelated pieces of functionality.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
NASM would try to "eat the comma token" in db expressions, even for
cases where the token was not a comma. Fix that and error out
properly.
To give better error messages, track where in the input string a token
starts or ends. This information is only valid as long as the input
string is kept, but that is just fine for error messages during
parsing.
Reported-by: Peter Cordes <pcordes@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Document CPU LATEVEX and the associated prefixes; add CPU EVEX and CPU
VEX flags to further control encodings.
Fix the error message for invalid encodings due to flags.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the %abs() function, to produce the absolute value as an
always-positive decimal constant.
Change the order of the arguments for %num().
Refactor the handling of optional arguments, to reduce the amount of
redundant code. This is currently only used for builtin functions, but
might be extended in the future.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
RDOFF has been deprecated as it has unfixable problems, and has been
announced that it will be killed off in NASM 2.16.
This deletes it once and for all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a {rex} prefix to force REX encoding (typically a redundant 40h
prefix).
For prefix parsing, we can use t_inttwo to encode the prefix slot
number.
Give more verbose error messages for encoding mismatches.
NASM 2.15.04
Conflicts:
asm/listing.h
asm/pptok.pl
asm/preproc.c
version
This doesn't pass travis test 3392711, which is using an extremely odd
construct of %?? in the middle of an argument sequence for an smacro
while not being in a macro itself, and expecting it to expand to the
macro name. This seems to *really* confuse the master branch.
Resolve this later...
The VPCMP instructions are controlled by an immediate byte, but there
is also a set of SSE-derived legacy opcodes for VPCMPEQ and
VPCMPGT. For the specific cases of VPCMPEQ and VPCMPGT, prefer those
opcodes since they are one byte shorter.
Reported-by: ig <glucksmann@avast.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
After issuing an error message for a missing %stacksize argument, need
to quit rather than continuing to try to access the pointer.
Fold uses of tok_text() while we are at it.
Reported-by: Suhwan <prada960808@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
An eop may have a data buffer associated with it as part of the same
memory allocation. Therefore, we need to move "subexpr" up instead of
merging it into "eop".
This *partially* resolves BR 3392707, but that test case still
triggers a violation when using -gcv8.
Reported-by: Suhwan <prada960808@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Break the instruction processing if there are impossible combinations
of Sx flags and operand sizes. If the intent is to always require
explicit sizes, use the SX flag.
The INSERTPS instruction pattern was explicitly wrong, the rest of
these are nuisance fixes.
TODO: fix the disassembler to be able to exclude patterns where these
bits don't matter.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
It seems that the odd alignment-padding code was simply dead in older
versions of NASM. This means that the COFF backend behavior really was
the same as the other backends. Remove that stale code and revert to
previous/common behavior.
Reported-by: ig <glucksmann@avast.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The %? and %?? tokens are ambiguous when used inside a multi-line
macro. Add tokens %*? and %*?? that only expand during single-macro
expansion.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Support generating bfloat16 constants. This is a bit awkward, as "DW"
already generates IEEE half precision constants; therefore there is no
longer a single floating-point format for each size. This requires
some replumbing.
Fortunately bfloat16 fits in 64 bits, so support generating them with
a macro that uses __?bfloat16?__() to convert to integers first before
passing them to DW.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a couple of dd/db directives to ppindirect.asm to make it possible
to actually run it through the assembler.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Disable the %pragma list options in k_test.asm to avoid nasty
surprises. LISTOPT is -L+ by default and can be overridden on the
command line, so the %pragma is not just unnecessary but problematic.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If a format is specified explicitly for the debug format, it needs to
be "debug", not "dbg". Lovely inconsistency.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
1. Error messages would issue with the line number of %endrep.
2. Debug line information would ignore both macros and reps.
This is doubly wrong; macros are semantically equivalent to
inline functions, and it is expected that debuggers trace
into these functions.
These changes finishes the last parts of moving all responsibility for
the listing enable/disable into the preprocessor, so remove the
way over-complicated macro inhibit facility from the listing module
entirely.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Fix the handling of %{:} macro operands. Use the same code for
expanding the subarguments as for normal arguments.
This (hopefully) resolves the following bug reports:
BR 3392611, BR 3392686, BR 3392688
Reported-by: <coconutfaistoslimeregistry@gmail.com>
Reported-by: Jasper Lievisse Adriaanse <r+nasm@jasper.la>
Reported-by: Jason Hood <jadoxa@yahoo.com.au>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
