When throwing one of the "instruction expected" error messages, print
what was encountered instead.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Remove the legacy output entry point. It has proven impossible to find
the time to completely port the backends all at once.
Instead, always generate the legacy output data, but put them into the
out_data structure. Then add a macro to explode these arguments into
separate variables, equivalent to the old function arguments. This
also centralizes the type definitions for these variables.
Most importantly, it means that the entire struct out_data is now
always available, which means that backends that need the additional
information available in that structure, such as the specific
instruction template, can access that information without needing to
revamp the entire backend code all at once.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This code incorrectly would try to use "path" as the hash key instead
of full->path, causing the key in struct hash_insert to diverge from
the one used in hash_add(). Fix that.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Under some circumstances, such as:
- Certain uses of %exitrep in syntactically invalid code;
- %unmacro of a *alias* to a macro currently being expanded;
... it is possible for an mmacro to get freed while it is still in
use. Although inefficient, the easiest way to avoid this is to not
free mmacros until the end of pass cleanup, when named mmacros are
also freed.
To support this, use the existing ->next field in the MMacro structure
to keep a list of anonymous or removed MMacros. Don't free ->name at
this point, though, since that is currently used to distinguish
between %rep's and %macro's. (This needs to be cleaned up to support
constructs such as %while or %for, but that is for later.)
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add a optimization frameword for operand narrowing (where the operand
size doesn't matter beyond a certain range because only certain bits
are referenced.)
Add a macro *and* matching facility for dealing with segment selectors, which are
typically rm16/r32/r64, but exactly how that is applied varies
depending on if a datum is read or written.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
More work on cleaning up instruction patterns, fixing matchig corner
cases, and tidying up the organization of insns.dat.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
Tag pseudo-instructions explicitly and don't set any CPU level flag
for those.
Change insnsa.c to have (length, pointer) rather than using an ever
increasing in size sentinel at the end of each table. This also means
that empty tables (Dx, INCBIN) can be omitted entirely.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add more instruction macros and fix problems. Adjust some matching
problems.
Remove all FUTURE tags from the instruction list, and add a bunch of
new CPUID tags. Hopefully a small step toward actually getting CPU
feature selection working properly in the future.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"nw" now means: 64-bit operand size is the default, o32 is not
permitted in 64-bit mode.
"osz" means: instruction size determined by prefixes, otherwise the
mode default.
Signed-off-by: H. Peter Anvin <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>
Don't do an out-of-range check for the operands, even
temporarily. Setting the operand pointer to NULL will help catch
errors when accessing non-operands, too.
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>
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>
We use this all over the place, so make these general. The sign
extension function existed as signed_bits(), but that is an awfully
confusing name.
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>
If TOKEN_BRCCONST are used in an expression (including simply wrapping
them in parentheses), then just treat them as integers. This makes
things like ({dfv=cf}|{dfv=of}) work.
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>
The parser state does not just necessarily include the position of the
buffer, but make it possible to maintain additional state.
Furthermore, add an explicit ability to push back a token.
All of this might make it easier at some point in the future to keep
track of horizontal position, although that will require lots of
changes to the preprocessor.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Clean up the handling of prefixes in general. Allow a set of braced
prefixes to follow the instruction; this is required for things like
{dfv=} but might also be a nicer syntax for things like {rex}.
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>
The help output has gotten way too long to be shown on a single
command line. It can of course be piped to a pager, but to be a little
nicer to the user, break it up into subtopics that can be individually
displayed. --help all (-h all) can still show all the help information
as a single data dump.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Try to better sort out the necessary dependencies for warning
generation.
Fix regex for cleaning up nasmdoc markup: nasmdoc markup does not
nest, although it may include \} sequences.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We should always support up to 8 characters, i.e. 64 bits, in a
string-to-numeric conversion.
Reported-by: Aleksandras Krupica <vaikutisasa@gmail.com>
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 ability to have fixed arguments in %map. This is extremely
useful for parameterizing the invoked macro using arguments to a
surrounding macro.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Separate out counting and parsing smacro parameters into separate
functions. This not only makes the code *way* easier to read, but
these can be re-used e.g. for %map().
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>
When expanding %rep blocks, if any of the %rep blocks are empty, there
may be need to unwind the %rep stack multiple times. The code would
not do so -- there was a break; in the loop, which incidentally turned
it into something that wasn't a loop at all.
Reported-by: E. C. Maslock <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
