Clean up the formatting of the BMI instruction patterns, and fix:
a) X64,FUTURE is wrong - it needs to be LONG,FUTURE
b) Fix the BLSI, BLSMSK, BLSR instruction patterns
c) Use a bracket pattern for TZCNT
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
As HPA explained
|
| w.r.t. the -QQ- instruction forms... when we did
| the initial AVX implementation we decided that
| using -DQ- (double quadword) for 256-bit instructions
| was a bit messy, so we decided to accept both -DQ-
| (being official) and -QQ-
|
So move VLDQQU back and place it before VLDDQU so disassembler
match it first.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This form of VPEXTRW is that named 'B' form so
operands encoding should be fixed.
Reported-by: Jasper Neumann
Patch-by: Jasper Neumann
CC: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In fact it was written as
MOVAPS xmmreg,xmmreg \360\2\x0F\x28\110 KATMAI,SSE
MOVAPS xmmreg,xmmreg \360\2\x0F\x29\101 KATMAI,SSE
in first place
MOVUPS xmmreg,xmmreg \360\2\x0F\x10\110 KATMAI,SSE
MOVUPS xmmreg,xmmreg \360\2\x0F\x11\101 KATMAI,SSE
and for example x28 stands for xmmrm128,xmmreg and
x1 for xmmrm128,xmmreg.
TODO: Inspect and fix WILLAMETTE instructions.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Handle immediate-size optimization for "mov r64,imm" -- reduce it to
"mov r32,imm32" or "mov r64,imm32" as appropriate.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Allow implicit operands for VBLENDVP, just as for other instructions,
since the semi-legacy forms now are removed.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Version 7 of the AVX spec specifically forbids (#UD) using the
66 0F 38 14/15 forms of the BLENDV instructions with a VEX prefix;
those encodings are strictly legacy SSE 4.1.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Updates from the AVX version 7 specification: mostly tightening of the
rules for VEX.L and VEX.W, but remove the VPERMIL2 instructions.
Also encode all the full-length forms of the VCMP instructions and
prefer those for the disassembly.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add FXSAVE64 and FXRSTOR64; drop the np prefix on 0F AE instructions:
none of the rest of the 0F AE instructions have them, and there are no
conflicts.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
FUTURE is a CPU level flag, and cannot be combined with X64 (which is
shorthand for X86_64,LONG). Also, make sure we add LONG annotations
to everything that is 64-bit mode only.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the RD*SBASE, WR*SBASE and RDRAND instructions from version 7 of
the AVX specification, Intel document 319433-007.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
PUSH imm64 confuses ones who is trying to find this instruction in
processor programming manuals.
Actually it was introduced in a sake of "push `size' imm" consistency.
In other words -- to allow users to state "PUSH qword imm32" in 64bit code,
though on byte level (ie generated) code it still has a correct and valid
sign-extended "PUSH imm32" instruction.
To get rid of this ambiguie bite we make explicit "PUSH imm32"
being valid in 64bit code. This also makes "PUSH dword imm32"
valid in 64bit code as well.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The former changes have been committed to binutils.
From initial message:
|
| 2010-03-22 Quentin Neill <quentin.neill@amd.com>
| Sebastian Pop <sebastian.pop@amd.com>
|
| opcodes/
| * i386-dis.c (OP_LWP_I): Removed.
| (reg_table): Do not use OP_LWP_I, use Iq.
| (OP_LWPCB_E): Remove use of names16.
| (OP_LWP_E): Same.
| * i386-opc.tbl: Removed 16bit LWP insns. 32bit LWP insns
| should not set the Vex.length bit.
| * i386-tbl.h: Regenerated.
|
| gas/
| * testsuite/gas/i386/x86-64-lwp.s: Remove use of 16bit LWP insns.
| * testsuite/gas/i386/lwp.s: Same.
| * testsuite/gas/i386/x86-64-lwp.d: Updated.
| * testsuite/gas/i386/lwp.d: Updated.
|
So there is no 16 bit instructions anymore.
Also xop.l field should be set to 0.
Based on patch from nasm64developer
Reported-by: nasm64developer
Signed-off-by: nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The first argument to MONITOR is an address, so it should be 64 bits
(RAX) in 64-bit mode.
The preferred form is still just plain "monitor".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
nasm64developer reported that we have no LWP support yet.
Add this feature.
Reported-by: nasm64developer <nasm64developer@users.sf.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
nasm64developer reported a few nits in XOP
instruction templates. Plain typo in specification
(http://support.amd.com/us/Processor_TechDocs/43479.pdf)
and opcode errors.
Reported-by: nasm64developer <nasm64developer@users.sf.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
nasm64developer reported that VFNMADDSD and VFNMADDSS
have "m" and "s" operands swapped in instruction templates
file.
Reported-by: nasm64developer <nasm64developer@users.sf.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
During conversion of size of memory operands into
explicit form the compatibility with 2.07 has been
broken (for a small set of instructions). Lets restore
it. Details below.
This is due to specifics of our "fuzzy logic" algorithm.
For example consider the user wrote an instruction like
VCVTTPD2DQ xmm0,[eax]
the last operand is memory reference. But template contains
the following two items (written in simplified form)
VCVTTPD2DQ xmmreg,mem128
VCVTTPD2DQ xmmreg,mem256
So this is impossible to find out what _exactly_ user meant:
either reference to 128 bit value in memory or 256 bit.
As a solution we've been using IF_Sx modifier written in
template which allows to choose "by-default" template
and break the tie.
Reported-by: Victor van den Elzen <victor.vde@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Even the non-DREX SSE5 instructions appear to have been either
obsoleted or replaced with XOP varieties. The only exception are the
ROUNDxx instructions, which are really SSE4.1 instructions and which
were simply duplicates.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
One more incorrect use of sbyte in IMUL.
Overall, the IMUL patterns seem really messy. *Furthermore*, despite
IMUL normally being thought of as signed, the 2- and 3-operand
versions don't produce a high half and are therefore
signedness-agnostic -- we could even add MUL patterns for those forms.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
