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>
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>
Fix a very curious transposition in the instruction patterns for IMUL,
which caused 32-bit IMUL instructions with constants like 0x10001 to
be generated incorrectly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Convert Intel AVX instructions to explisit size
format. Part 2.
Also CLMUL converted as well.
Btw, VPINSR was a bit broken since SB constraint
is not applied on all forms but requires 16,32,64
memory sizes too. Fixed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Convert Intel AVX instructions to explisit size
format. Part 1.
Also SAR instruction is touched as well.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Fix the disassembly of JRCXZ; in 64-bit mode, we should only accept
JECXZ for disassembly with 32-bit address size override.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change the relaxed forms to the compact representation. This
*deliberately* does not fix bugs where the relaxed form does not match
the official form; this is strictly a "no change in output" checkin.
All remaining open-coded relaxed forms are very likely bugs, and need
to be individually audited. Furthermore, it is questionable if the
Intel FMA instructions, being destructive, should have relaxed forms
at all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
1) A number of PMA -> VPM misprint fixed.
2) Spec points to ymmreg in mnemonics even for L=0 instructions. Fixed.
The instructions are still sorted in order of specification follows.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Introduce base XOP/FMA4/CVT16 instructions (SSE5)
based on official specification from AMD (rev 3.03).
Some fixes from Peter Johnson and H. Peter Anvin
included (not updated in AMD spec yet).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Two bugs with respect to the FMA instructions:
- the variant increment is supposed to be 0x10, not 0x01.
- the base opcode for scalar VFNMADD is 0x9d, not 0x9c
The Perl script which auto-generated the VFM instructions had
incorrectly conflated the VEX.W and VEX.L bits, with the result that
only half the valid instructions were generated.
