* x86arch.h (x86_new_insn_data): Add shortmov_op for shortmov post-action.
* x86bc.c (x86_insn): Likewise.
(yasm_x86__bc_create_insn): Copy shortmov_op to instruction.
(x86_bc_insn_resolve): Handle shortmov_op post-action.
* x86id.re (yasm_x86__parse_insn): Set shortmov_op post-action if desired.
* x86id.re (mov_insn): Through reorder and use of new shortmov_op
post-action, change generated code for mov on AMD64. On AMD64, the short
mov (opcode A0/A1/A2/A3), generated when moving to AL/AX/EAX/RAX from an
absolute address (no registers) has a 64-bit size in 64-bit mode. While an
address override can reduce it to 32-bits, automatically generating such an
override does not fit well with the model of not doing anything behind the
programmer's back. Instead, we now generate the 32-bit address size MOD/RM
form unless the address size is specifically set to 64 bits using [qword 0]
notation (this is the equivalent of the GNU AS movabs pseudo-instruction).
The short mov is still generated in 32-bit mode, whether obtained via BITS
setting or an a32 prefix in BITS 64 mode. (The a32 prefix handling
necessitated the new shortmov post-action.) Examples (pulled from new
mem64.asm):
mov ax, [0] ; 66 8B 04 25 00 00 00 00
mov rax, [dword 0] ; 48 8B 04 25 00 00 00 00
mov al, [qword 0xfedcba9876543210] ; A0 10 32 54 76 98 BA DC FE
mov al, [0xfedcba9876543210] ; 8A 04 25 10 32 54 76 (+ warning)
a32 mov rax, [0] ; 67 48 A1 00 00 00 00
* mem64.asm: Update test to match code changes.
* mem64.hex: Likewise.
* mem64.errwarn: Likewise.
Related to: Bugzilla Bug 33
Reported by: Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1134
preventing a segfault. The assumptions it had made for all sections
were wrong with absolute sections, so added just as much special casing
as necessary. I hope the output is correct as well - this way we should
at least get bugs if it's wrong.
Reported by: Ben Skeggs <d4rk74m4@intas.net.au>
svn path=/trunk/yasm/; revision=1119
The AMD64 MASM likes to generate REL32 relocations for everything; I've not
yet figured out how this works.
This code should work fine for files without relocation.
Bugzilla bug: 33
Reported by: Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1113
This is primarily for users building yasm on Windows using VC++.
Bugzilla bug: 32
Reported by: jlawson-yasm@bovine.net
svn path=/trunk/yasm/; revision=1108
a non-multiplier used after a multiplier (e.g. edi*8+eax). Previously,
this resulted in the eax overriding the edi as the indexreg, causing the
effective address not to be recognized.
Update the effaddr testcase to test this case and a few other similar ones.
Bugzilla bug: 31
Reported by: vclaudepierre@tiscali.fr
svn path=/trunk/yasm/; revision=1106
64-bit immediate. Actually, whether it's signed or unsigned seems to be
uncertain; AMD64 documentation shows it as signed, but Intel's new IA-32e
says it's unsigned! While we're here, the Imm8 version is signed, not
unsigned.
Bugzilla bug: 30
Reported by: Michael Ryan <michaelryan@mindspring.com>
svn path=/trunk/yasm/; revision=1105
different location. The new code uses dirname() to add the argv[0] path to
the LTDL module loader search path. Added new replacements for dirname and
basename functions from OpenBSD.
Bugzilla: Bug 24
Reported by: Simon Paulger <simonjpaulger@hotmail.com>
svn path=/trunk/yasm/; revision=1098
(Hopefully) finish cleanups begun in phase 1 (see phase 1 commit message),
making dbgfmt, objfmt, optimizer, and preproc module interfaces follow the
same thread-safe interface style as the phase 1 changes.
Also put in a large number of doxygen documentation cleanups.
svn path=/trunk/yasm/; revision=1097
in 64-bit (AMD64) mode. Intel says these bytes should not be treated as
prefixes, but AMD64 treats them as legacy prefixes, expecting them to come
before the REX byte.
For now, keep the three-byte max instruction length (although it's not truly
correct), as handling the other "3-byte" cases such as R/M spare with no EA
is probably more painful than it's worth to push down to later in the code
generation path.
Reported by: Henryk Richter <henryk.richter@comlab.uni-rostock.de>
svn path=/trunk/yasm/; revision=1094
- PEXTRW
- MOVMSKPD
- MOVMSKPS
- PMOVMSKB
Reported by: Vivek Mohan <vivekm@phreaker.net>
Also, while we're here, fix all CVT* SIMD instructions; they were variously
incorrect (mostly with regards to accepted operands).
New testcase, simd-2, tests all the above (output verified with GNU objdump).
svn path=/trunk/yasm/; revision=1093
Currently requires Perl installed as \Program Files\Perl\bin\perl.
Contributed by: Brian Gladman <brg@gladman.plus.com>
svn path=/trunk/yasm/; revision=1090
use of the ORG macro (several user comments about the lack of this) and the
initial value of the __SECT__ macro (used by ENDSTRUC among other macros).
Fortunately, for all current objfmts, __SECT__ is currently defined as
[section .text], so one common definition can be used for now.
FIXME: remove this workaround when a better solution has been implemented.
svn path=/trunk/yasm/; revision=1087
NASM parser by changing the libyasm yasm_fatal() interface to use va_list
instead of ... variable arguments. Add a yasm__fatal() function that takes
... and calls yasm_fatal().
Bugzilla bug #22
Reported by: mu@tortall.net
svn path=/trunk/yasm/; revision=1086
values into 32bits as necessary. This is the proper fix to "written
length does not match optimized length" in amd64+stabs.
Reported by Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1084
Previously only "symvalue" stabs did this, causing a mismatched output size
with amd64 and stabs. However since it appears the actual stabs spec always
uses 12 byte stabs, this fix is already obsolete and will be superceded
shortly.
Reported By: Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1083
Peter Johnson
Michael Urman