| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Handle operand flags like "xmmrm128" correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
*To the best of my knowledge*, we now have authorization from everyone
who has significantly contributed to NASM in the past. As such,
change the license to the 2-clause BSD license.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
This adds copyright verbiage to the Perl scripts. Scripts that are
known to be clean w.r.t. the 2-clause BSD license are given that
license; unclear ones are given the "LGPL for now".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Clean up whitespace in insns.pl.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Add a "nohi" code flag for the \325 byte code, which sets the REX_NH
flag. That is, REX_P not required to support high registers, high
registers are not supported and spl/bpl/sil/dil enabled even in
non-64-bit mode.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Canonicalize indentation of some blocks.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Allow a * to be put on an operand, indicating that it is optional and
should be replaced with the immediately preceding operand if it is
omitted. This allows official and relaxed forms of nondestructive
instructions to be written on one line.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
We already have such kind of aliases for L field
(via l0 and l1). Via p0,p1,p2 it's become easier
to follow AMD docs while encoding VEX/XOP commands.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Use lower case for VEX and XOP ("vex", "xop") to avoid visual
confusion (and in the future potential real confusion) with upper-case
hexadecimal numbers.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Handle AMD's XOP prefixes; they use basically the same encoding as VEX
prefixes, so treat them simply as a variant of VEX.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
The AVX spec version 5 introduces the new VEX.DDS flag; support it.
|
|
The bytecode format assumes max 4 operands pretty strictly, but we
already have one instruction with 5 operands, and it's likely to get
more. Support them via extension prefixes (similar to REX prefixes).
For bytecodes which use argument bytes we encode the number directly,
however.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Reshuffle the bytecodes for segment register push/pop to make more
sense, and move them from \4 to \344, thus freeing up the single-digit
bytecodes \4..\7 for future use. It doesn't really make sense to use
single-digit bytecodes for this very oddball use.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
We are starting to have to worry about running short on available
bytecodes, especially where we encode the operand number in the byte
code. Thus, compile a table of bytecode usage and include as a
comment in insnsb.c.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Add a new opcode for 32->64 bit sign-extended immediate, with warning
on the number not matching.
This unfortunately calls for an audit of all the \4[0123] opcodes, if
they should be replaced by \25[4567]. This only replaces one
instruction (MOV reg64,imm32); other instructions need to be
considered.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
New opcodes to deal with 8-bit immediates which are then sign-extended
to the operand size. These allow us to warn appropriately.
Not sure I'm using these in all the proper places; need audit of all
uses of the \14..\17 opcodes.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
|
Be consistent about marking Perl scripts executable, even if we always
invoke them with $(PERL) in the Makefiles.
|
|
Some pseudo-instructions (RESB and EQU) seem to make it into the
instruction table. This also generates an instruction table for
zero-length instructions, which of course can never actually be
accessed. Quiet a compiler warning by simply not emitting this
useless table. Ideally we shouldn't emit the pseudo-instructions
either, but that is a bigger change, and it's hardly a lot of memory
involved.
|
|
Better error messages, and allow "void" instructions to omit the
operand colon.
|
|
Add vex.ww (for VEX.W follows REX.W) and vex.wx (for VEX.W is a don't
care); vex.wx is the default since that seems to match existing usage
better.
|
|
Although redundant, the presence of a 'v' operand should match the
existence of a nds or ndd flag on vex; this should help catch typos.
|
|
The disassembler code gets cleaner if we do *not* separate out the
conditional instructions; instead, rely on the fact that the
conditionals are always at the end and use FIRST_COND_OPCODE as a
barrier.
|
|
Adjust the compiler to give a syntax for DREX instructions that
matches the AMD documentation.
|
|
Use the somewhat more mnemonic "o64nw" for 64-bit operand size sans
REX.W.
|
|
Make insnsd.c a bit more consistent in style.
|
|
We can use the new VEX prefixes to select into a large table of new
opcode spaces. Since the table is (currently) sparse, add logic so we
don't end up producing tons of empty tables for no good reason.
This is also necessary since VEX is likely to reuse opcode bytes that
would appear as prefixes at some point, which would cause conflicts
with the regular tables.
|
|
The 0270 code was incorrectly entered as 270 (decimal), which meant
that instructions with vex but no .nds got misfiled in the improper
opcode tables.
|
|
Support is4 bytes without meaningful information in the bottom bits.
This is equivalent to /is4=0 for the assembler, but makes the bottom
bits don't care for the disassembler.
|
|
Use - to denote that an operand is implicit (not encoded). This
*better* be a fixed operand!
|
|
We had a completely unnecessary loop to test for conditional opcodes.
Since we always put the conditional opcodes at the end, we might as
well just remember where that list starts and compare against it.
|
|
Use a more manual-like syntax for immediates (we still may have to use
extended syntax, but not always.)
|
|
Don't #include .c files, even if they are auto-generated; instead
compile them as separate compilation units and let the linker do its
job.
|
|
Use Perl's context-sensitive regular expressions to tell split that a
slash or backslash begins a new operator.
|
|
Sometimes assembly syntax wants to permit a single operand to serve
multiple functions; allow this.
The disassembler could really use to be smarter about those.
|
|
The argument is now $1, not $2...
|
|
|
|
|
|
Properly done, all SSE instructions which has the 66/F2/F3 opcode
multiplex need two prefixes: one to control the use of OSP and one to
control the use of REP. However, it's a four-way select: np/66/F2/F3;
so introduce shorthand bytecodes for that purpose.
|
|
imz2 is just an alias for is4 as far as we are concerned...
|
|
In Perl code, it is good practice to escape special characters
intended to be literal.
|
|
|
|
More work on the bytecode compiler. Not all useful bytecodes are
implemented yet, however.
|
|
First steps toward a smart(er) bytecode compiler, using a syntax that
can be more directly taken from the manuals.
|
|
"make alldeps" doesn't really like it when included files end in *.c.
Instead of renaming insnsb.c to insnsb.h, make it an actual
compilation unit, since there really isn't any reason for it not to
be.
|
|
We already have indexes up to 9500, so use 5 digits instead of 4.
|
|
MAX_OPERANDS is present in insns.pl as well (although proper C
compilers shouldn't need this kind of zero padding.) Make sure it's
clear to everyone.
|
|
We can now have zero bytecodes with impunity, so remove any special
hacks we had to avoid zeroes in the bytecode.
|
|
Generate a byte array instead of using C compiler strings for the byte
codes. This has a few advantages:
- No need to special-case zero due to broken C compilers.
- Only insns.pl only ever reads the string, so we can invent our own
syntax.
- Compaction.
- We can give it the proper, unsigned type.
|
|
Factor out the string decoder into its own subroutine. This will be
useful shortly ;)
|
