Prior to this change: cpu_lcd(['AVX'], ['AVX','AES']) == ['AVX'],
causing AES instructions to be treated as unsupported when "cpu
WESTMERE" is used, or even "cpu WESTMERE AES".
Fixed by reordering ordered_cpu_features such that now,
cpu_lcd(['AVX'], ['AVX','AES']) == ['AES']. I don't know if there are
CPUs this would not be correct for, but this is the value that's
consistent with all extant CPU definitions.
MONITORX has opcode "0F 01 FA".
rAX contains address to be monitored
ECX specifies optional extensions
EDX specifies optional hints
MWAITX has opcode "0F 01 FA".
EAX specifies optional hints
ECX specifies optional extensions
Public documentation: http://support.amd.com/TechDocs/24594.pdf
New CLZERO instruction support (for 32bit/64bit)
* clzero has opcode "0F 01 FC".
* clzero gets enabled with CPUID, 8000_0008, EBX[0] =1.
* clzero instruction zero's out the 64 byte cache line specified in rAX. Bits 5:0 of rAX are ignored
Copyright (c) 2016 Advanced Micro Devices, Inc. All rights reserved.
Redistributed under simplified 2-clause BSD licence
XAXQUIRE
XRELEASE
XABORT
XBEGIN
XEND
XTEST
Also fixed a bug for CALL instruction (opcode 0xE8) - it allowed 16 bit operand with 0x66 prefix in 64 bit mode,
while 16 bit operand is not allowed at all in 64 bit mode.
Added X86_ACQREL prefix group for XACQUIRE/XRELEASE prefixes, since they need to be orthogonal to LOCKREP
prefixes, because TSX prefixes must come together with F0 (LOCK) prefix.
However this commit does not enforce using TSX hints only with instructions they are allowed to be used.
The reason for this is that lock prefix F0 itself is not enforced to be used only with lockable instructions, this seems to be a decision made by
Yasm developers, that user himself must take care of these situations.
Right now TSX hints can come with F0 prefix, can come with REPNE/REPZE prefixes, but they are used together in assembly, only the leftmost would be
encoded to the binary and warning will be issued. This is the behavior of Yasm for duplicate LOCKREP prefixes.
These instructions use "VSIB" encoding, which takes the place of the
usual SIB encoding. Several tests cover various legal and illegal
modes.
Last part of [#227 state:resolved].
Reference: http://www.intel.com/software/avx rev11 spec
This is all AVX2 instructions except for VGATHER*/VPGATHER*, which
require additional ModRM handling.
Portions contributed by: Mark Charney <mark.charney@intel.com>
Part of [#227].
Reference: http://www.intel.com/software/avx rev11 spec
Also add appropriate CPU bits and directive handling for these.
Currently we have no good way of handling an "or" of instruction bits
(in this case needed for LZCNT, where it's either AMD or LZCNT). For
now, make it LZCNT only.
Contributed by: Mark Charney <mark.charney@intel.com>
Part of [#227].
Previously a line such as "times 4 mov rax, [rel foobar]" would result
in incorrect relocations being generated.
Patch by: bird-yasm@anduin.net
[#211 state:resolved]
The register versions worked okay due to size matching, but the memory
versions relied on suffix matching, which wasn't being generated correctly.
Reported by: Tony Goelz <cag@absoft.com>
svn path=/trunk/yasm/; revision=2358
- Fix#193: ljmp/lcall not implemented; add 2-operand far jump to jmp/call.
- Add loop{,z,e} instruction suffixes
- Fix a bunch of jmp/call minor issues.
- Vastly improve suffix handling in general to make more consistent and make
a greater variety of no-suffix instructions work in a way that matches GAS.
svn path=/trunk/yasm/; revision=2238
AMD has obsoleted the SSE5 spec in favor of these instructions. These
instructions use an AVX-like new opcode structure called XOP instead of
the SSE5 DREX byte.
The AMD FMA4 instructions are a copy of the *old* Intel FMA instructions.
Intel has since updated their spec, and AMD may follow, but for now we've
implemented what AMD's spec contains.
svn path=/trunk/yasm/; revision=2199