Now that we have identifiers for the mnemonic strings we can avoid
opcode based comparisons, for (in many cases) being more expensive and
(in a few cases) being a little fragile and not self-documenting.
In preparation for changing the representation of the "name" field
introduce a wrapper function. This keeps the mechanical change separate
from the functional one.
The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
Have its use, except where actually legitimate, result in the same "only
supported in 64-bit mode" diagnostic as emitted for other 64-bit only
insns. Also suppress deriving of the suffix in Intel mode except in the
legitimate cases. This in exchange allows dropping the respective code
from match_template().
To maintain reasonable diagnostics (in particular to avoid "`mov' is
only supported in 64-bit mode" on the SIMD forms of MOVQ) we need to
defer parse_insn()'s emitting of errors unrelated to prefix parsing.
Utilize i.error just like match_template() does.
Oddly enough despite gcc's preference towards FILDQ and FIST{,T}Q we
had no testcase whatsoever for these. Therefore such tests are being
added. Note that the removed line in the x86-64-lfence-load testcase
was redundant with the exact same one a few lines up.
Having templates with a suffix explicitly present has always been
quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
a suitable template _and_ didn't itself already need to trim off a
suffix to find a match at all. This requires error reporting adjustments
(albeit luckily fewer than I was afraid might be necessary), as errors
previously reported during matching now need deferring until after the
2nd pass (because, obviously, we must not emit any error if the 2nd pass
succeeds). While also related to PR gas/29524, it was requested that
move-with-sign-extend be left as broken as it always was.
PR gas/29525
Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
templates taking operands, mixed IsString/non-IsString template groups
(with memory operands) cannot occur anymore. With that
maybe_adjust_templates() becomes unnecessary (and is hence being
removed).
PR gas/29526
Note further that while the additions to the intel16 testcase aren't
really proper Intel syntax, we've been permitting all of those except
for the MOVD variant. The test therefore is to avoid re-introducing such
an inconsistency.
With the removal of its use for FPU insns the suffix is now finally
properly misnamed. Drop its use altogether, replacing it by a separate
boolean instead.
As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)
In "x86/Intel: restrict suffix derivation" I think I screwed up
slightly, bringing a piece of code out of sync with its comment, and
resulting in a suffix potentially being derived when one isn't needed.
Both uniformly only ever take 16-bit memory operands while at the same
time requiring matching (in size) register operands, which then also
should disassemble that way. This in particular requires splitting each
of the templates for the assembler and separating decode of the
register and memory forms in the disassembler.
While in some cases deriving an AT&T-style suffix from an Intel syntax
memory operand size specifier is necessary, in many cases this is not
only pointless, but has led to the introduction of various workarounds:
Excessive use of IgnoreSize and NoRex64 as well as the ToDword and
ToQword attributes. Suppress suffix derivation when we can clearly tell
that the memory operand's size isn't going to be needed to infer the
possible need for the low byte/word opcode bit or an operand size prefix
(0x66 or REX.W).
As a result ToDword and ToQword can be dropped entirely, plus a fair
number of IgnoreSize and NoRex64 can also be got rid of. Note that
IgnoreSize needs to remain on legacy encoded SIMD insns with GPR
operand, to avoid emitting an operand size prefix in 16-bit mode. (Since
16-bit code using SIMD insns isn't well tested, clone an existing
testcase just enough to cover a few insns which are potentially
problematic but are being touched here.)
Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI
isn't included there. This is to fulfill the request of not allowing L
and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI.
The only case where 64-bit code uses non-sign-extended (can also be
considered zero-extended) displacements is when an address size override
is in place for a memory operand (i.e. particularly excluding
displacements of direct branches, which - if at all - are controlled by
operand size, and then are still sign-extended, just from 16 bits).
Hence the distinction in templates is unnecessary, allowing code to be
simplified in a number of places. The only place where logic becomes
more complicated is when signed-ness of relocations is determined in
output_disp().
The other caveat is that Disp64 cannot be specified anymore in an insn
template at the same time as Disp32. Unlike for non-64-bit mode,
templates don't specify displacements for both possible addressing
modes; the necessary adjustment to the expected ones has already been
done in match_template() anyway (but of course the logic there needs
tweaking now). Hence the single template so far doing so is split.
MASM doesn't support the separate operand form; the modifier belongs
after the instruction instead. Accept this form alongside the original
(now legacy) one. Short of having access to a MASM version to actually
check in how far "after the instruction" is a precise statement in their
documentation, allow both that and the SDM mandated form where the
modifier is on the last register operand (with a possible immediate
operand following).
Sadly the split out function, at least for the time being, needs to cast
away constness at some point, as the two callers disagree in this
regard.
Adjust some, but not all of the testcases.
As a preparatory step to allowing proper non-operand forms of specifying
embedded rounding / SAE, convert the internal representation to non-
operand form. While retaining properties (and in a few cases perhaps
providing more meaningful diagnostics), this means doing away with a few
hundred standalone templates, thus - as a nice side effect - reducing
memory consumption / cache occupancy.
MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Accept these forms
alongside the original (now legacy) ones.
Acceptance of the original {1to<n>} operand suffix is retained both for
backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
conversions with shrinking element sizes. I have no insight (yet) into
how MASM expects those to be disambiguated.
Adjust some, but not all of the testcases.
Allow transitive (or recursive) equates to work in addition to direct
ones. The only requirements are that
- the equate being straight of a register, i.e. no expressions involved
(albeit I'm afraid something like "%eax + 0" will be viewed as %eax),
- at the point of use there's no forward ref left which cannot be
resolved, yet.
PR gas/28977
Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
i386_parse_name() to call parse_register(). This being a hook from the
expression parser, it shouldn't be resolving e.g. equated symbols.
That's relevant only for all other callers of parse_register().
To compensate, in Intel syntax mode check_register() needs calling;
perhaps not doing so was an oversight right when the function was
introduced. This is necessary in particular to force EVEX encoding when
VRex registers are used (but of course also to reject bad uses of
registers, i.e. fully matching what parse_register() needs it for).
The result of running etc/update-copyright.py --this-year, fixing all
the files whose mode is changed by the script, plus a build with
--enable-maintainer-mode --enable-cgen-maint=yes, then checking
out */po/*.pot which we don't update frequently.
The copy of cgen was with commit d1dd5fcc38ead reverted as that commit
breaks building of bfp opcodes files.
The former two are unused anyway. And having such constants isn't very
helpful either, when they live in a place where updating the register
table wouldn't even allow noticing the need to adjust these constants.
Just like is already done for VEX/XOP/EVEX encoded insns, record the
encoding space information in the respective opcode modifier field. Do
this again without changing the source table, but rather by deriving the
values from their existing source representation.
Just like is already done for legacy encoded insns, record the mandatory
prefix information in the respective opcode modifier field. Do this
without changing the source table, but rather by deriving the values from
their existing source representation.
Commit 8b65b8953af2 ("x86: Remove the prefix byte from non-VEX/EVEX
base_opcode") dropped the mandatory prefix bytes from legacy encoded
insn templates, but failed to also adjust affected MPX-specific checks
in two places.
For the expressions to remain halfway readable, introduce local
variables to hold current_templates->start.
PR gas/4572
When / is a comment character, its use as binary "divide" operator needs
escaping by a backslash. Besides the scrubber needing to support this
(addressed in an earlier change), there are also a few provisions needed
in target specific operator handling.
As the spec calls for % and * to also be escaped because of being
"overloaded", also recognize these, despite the overloading there not
really preventing their use as operators in most (%) or all (*) cases,
given the way how the rest of the assembler works.
To bring source and testsuite in line, also drop the TE_I386AIX part of
the respective conditional, as i?86-*-aix* support had been removed a
while ago.
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 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.
