AMD and Intel differ in their handling of far indirect branches as well
as LFS/LGS/LSS: AMD CPUs ignore REX.W while Intel ones honors it. (Note
how the latter three were hybrids so far, while far branches were fully
AMD-like.)
In memory operand addressing, which forms of displacement are permitted
besides Disp8 is pretty clearly limited
- outside of 64-bit mode, Disp16 or Disp32 only, depending on address
size (MPX being special in not allowing Disp16),
- in 64-bit mode, Disp32s or Disp64 without address size override, and
solely Disp32 with one.
Adjust assembler and i386-gen to match this, observing that templates
already get adjusted before trying to match them against input depending
on the presence of an address size prefix.
This adjustment logic gets extended to all cases, as certain DispNN
values should also be dropped when there's no such prefix. In fact
behavior of the assembler, perhaps besides the exact diagnostics wording,
should not differ between there being templates applicable to 64-bit and
non-64-bit at the same time, or there being fully separate sets of
templates, with their DispNN settings already reduced accordingly.
This adjustment logic further gets guarded such that there wouldn't be
and Disp<N> conversion based on address size prefix when this prefix
doesn't control the width of the displacement (on branches other than
absolute ones).
These adjustments then also allow folding two MOV templates, which had
been split between 64-bit and non-64-bits variants so far.
Once in this area also
- drop the bogus DispNN from JumpByte templates, leaving just the
correct Disp8 there (compensated by i386_finalize_displacement()
now setting Disp8 on their operands),
- add the missing Disp32S to XBEGIN.
Note that the changes make it necessary to temporarily mark a test as
XFAIL; this will get taken care of by a subsequent patch. The failing
parts are entirely bogus and will get replaced.
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 dc2be329b9 ("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 dc2be329b9 ("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
dc2be329b9 ("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 dc2be329b9 ("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
dc2be329b9 ("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 dc2be329b9 ("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.
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.
Alan Modra
Jan Beulich
Nick Clifton
Jan Beulich
H.J. Lu
Igor Zamyatin
Tristan Gingold