This is an alias of "qword ptr", commonly used with MMX insns.
At this occasion also test (alongside the newly supported "mmword")
- "zmmword" used as expression,
- PADDB with "oword ptr" (aliasing "xmmword ptr").
Commit dc2be329b950 ("i386: Only check suffix in instruction mnemonic")
broke rejecting of these for floating point insns. Fix this by setting
the "byte" operand attribute, which will now (again) cause an error.
Furthermore the diagnostic for the "far ptr" case in general and for the
"near ptr" case in the non-float cases became "invalid instruction
suffix" instead of the intended "operand size mismatch". Fix this by
also setting the "tbyte" operand attribute (no insn template accepts
both byte and tbyte operands).
There are extremely few insns accepting "tbyte ptr" operand, so the
"tbyte" operand flag checking done by match_operand_size() is already
sufficient; the setting of the suffix has become meaningless anyway
with dc2be329b950 ("i386: Only check suffix in instruction mnemonic").
Fold the code with that setting the "byte" operand flag to force an
error (no insn at all accepts both "byte ptr" and tbyte ptr" operands,
except for AnySize ones where the two (conflicting) recorded types
don't matter (operand_size_match() doesn't call match_operand_size() in
this case).
No floating point insn accepts an "fword ptr" operand, so the "fword"
operand flag checking done by match_mem_size() is already sufficient;
the setting of the suffix has become meaningless anyway with
dc2be329b950 ("i386: Only check suffix in instruction mnemonic").
LDS et al don't accept "word ptr" operands anyway, as per their insn
templates. Hence there's no need to special case this here; the check
has become dysfunctional anyway by dc2be329b950 ("i386: Only check
suffix in instruction mnemonic").
Since we accept these without suffix / operand size specifier, we should
also do so with one. (The fact that we unilaterally accept these, other
than far branches, rather than limiting them to Intel64 mode, will be
taken care of later on.)
Also take the opportunity and make sure "lfs <reg>, tbyte ptr <mem>"
et al get rejected outside of 64-bit mode. This became broken by
dc2be329b950 ("i386: Only check suffix in instruction mnemonic").
Furthermore cover lgdt et al in the Intel syntax handling as well, which
continued to work after said commit just by coincidence.
While dc2be329b950 ("i386: Only check suffix in instruction mnemonic")
has made the assembler accept these in the first place (they were wrongly
rejected before), the generated code was still wrong in that it lacked
an operand size override. (In 64-bit code, other than in 16- and 32-bit
ones, CALL and JMP with memory operands are all entirely unambiguous: No
operand size can have two meanings.)
They're the only exception to there generally being no mix of register
kinds possible in an insn operand template, and there being two bits per
operand for their representation is also quite wasteful, considering the
low number of uses. Fold both bits and deal with the little bit of
fallout.
Also take the liberty and drop dead code trying to set REX_B: No segment
register has RegRex set on it.
Additionally I was quite surprised that PUSH/POP with the permitted
segment registers is not covered by the test cases. Add the missing
pieces.
They aren't really useful (anymore?): The conflicting operand size check
isn't applicable to any insn validly using respective memory operand
sizes (and if they're used wrongly, another error would result), and the
logic in process_suffix() can be easily changed to work without them.
While re-structuring conditionals in process_suffix() also drop the
CMPXCHG8B special case in favor of a NoRex64 attribute in the opcode
table.
Use a combination of a single new Reg bit and Byte, Word, Dword, or
Qword instead.
Besides shrinking the number of operand type bits this has the benefit
of making register handling more similar to accumulator handling (a
generic flag is being accompanied by a "size qualifier"). It requires,
however, to split a few insn templates, as it is no longer correct to
have combinations like Reg32|Reg64|Byte. This slight growth in size will
hopefully be outweighed by this change paving the road for folding a
presumably much larger number of templates later on.
While we shouldn't outright reject such (as was wrongly done by commit
4d36230d59 ("x86: Update segment register check in Intel syntax"), as
MASM accepts them even silently, issue (by default) a warning for such
questionable constructs.
This reverts commit 4d36230d59903b92fbe2b53b31ed64a884860f0e.
I was committed without maintainer ack and regresses intended
functionality. A replacement will be committed shortly.
Multiple errors are more confusing than helpful, as the more generic
one often implies a sufficiently different adjustment than would
actually be needed to fix the code. Additionally it makes it more
cumbersome to add missing error checks, as the testsuite then needs
extra updating.
... rather than silently dropping it altogether.
i386_finalize_displacement() expects baseindex to already be set, so
the respective statement needs to be moved up. This then also allows a
subsequent conditional to be simplified.
For this to not regress on 32-bit addressing, break out address size
guessing from i386_index_check(), invoking the new function earlier so
that i386_finalize_displacement() has i.prefix[ADDR_PREFIX] available.
i386_addressing_mode () in turn needs i.base_reg / i.index_reg set
earlier.
The dual purpose mnemonic (string move vs scalar double move) breaks
the assumption that the isstring flag would be set on both the first
and last entry in the current set of templates, which results in bogus
or missing diagnostics for the string move variant of the mnemonic.
Short of mostly rewriting i386_index_check() and its interaction with
the rest of the code, simply shrink the template set to just string
instructions when encountering the second memory operand, and run
i386_index_check() a second time for the first memory operand after
that reduction.
2013-10-10 Jan Beulich <jbeulich@suse.com>
* tc-i386-intel.c (i386_intel_simplify_register): Suppress base/index
swapping for bndmk, bndldx, and bndstx.
operand, by silently making it the base register despite not being
specified first.
Consequently, we also permit an xmm/ymm index to be specified first
(possibly alone), nevertheless putting it in as index register.
2012-07-24 Jan Beulich <jbeulich@suse.com>
* config/tc-i386-intel.c (i386_intel_simplify_register): Handle
xmm/ymm index register being specified first as well as esp/rsp
base register being specified last in a memory operand.
gas/
2010-04-21 H.J. Lu <hongjiu.lu@intel.com>
PR gas/11509
* config/tc-i386-intel.c (i386_intel_simplify_register): New.
(i386_intel_simplify): Use i386_is_register and
i386_intel_simplify_register. Set X_md for O_register and
check X_md for O_constant.
(i386_intel_operand): Use i386_is_register.
* config/tc-i386.c (i386_is_register): New.
(x86_cons): Initialize the X_md field. Use i386_is_register.
(parse_register): Use i386_is_register.
(tc_x86_parse_to_dw2regnum): Likewise.
gas/testsuite/
2010-04-21 H.J. Lu <hongjiu.lu@intel.com>
PR gas/11509
* gas/i386/equ.s: Add tests for ".equ symbol, reg + NUM".
* gas/i386/equ.d: Updated.
