Change
67 48 8b 1c 25 ef cd ab 89 mov 0x89abcdef(,%eiz,1),%rbx
to
67 48 8b 1c 25 ef cd ab 89 mov 0x89abcdef,%rbx
in AT&T syntax and
67 48 8b 1c 25 ef cd ab 89 mov rbx,QWORD PTR [eiz*1+0x89abcdef]
to
67 48 8b 1c 25 ef cd ab 89 mov rbx,QWORD PTR ds:0x89abcdef
in Intel syntax.
gas/
PR gas/26237
* testsuite/gas/i386/evex-no-scale-64.d: Updated.
* testsuite/gas/i386/addr32.d: Likewise.
* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/x86-64-addr32.d: Likewise.
opcodes/
PR gas/26237
* i386-dis.c (OP_E_memory): Don't display eiz with no scale
without base nor index registers.
Irrespective of their encoding the resulting output should look the
same. Therefore wire the handling of PUSH/POP with GPR operands
encoded in the main opcode byte to the same logic used for other
operands. This frees up yet another macro character.
"Unambiguous" is is in particular taking as reference the assembler,
which also accepts certain insns - despite them allowing for varying
operand size, and hence in principle being ambiguous - without any
suffix. For example, from the very beginning of the life of x86-64 I had
trouble understanding why a plain and simple RET had to be printed as
RETQ. In case someone really used the 16-bit form, RETW disambiguates
the two quite fine.
Since the addr32 (0x67) prefix zero-extends the lower 32 bits address to
64 bits, change disassembler to zero-extend the lower 32 bits displacement
to 64 bits when there is no base nor index registers.
gas/
PR gas/26237
* testsuite/gas/i386/addr32.s: Add tests for 32-bit wrapped around
address.
* testsuite/gas/i386/x86-64-addr32.s: Likewise.
* testsuite/gas/i386/addr32.d: Updated.
* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/x86-64-addr32.d: Likewise.
* testsuite/gas/i386/ilp32/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/ilp32/x86-64-addr32.d: Likewise.
opcodes/
PR gas/26237
* i386-dis.c (OP_E_memory): Without base nor index registers,
32-bit displacement to 64 bits.
ARC can use odd-even double register pairs in some selected
instructions. Although the GNU assembler doesn't allow even-odd
registers to be used, there may be cases when the disassembler is
presented with such situation. This patch add a test and detects such
cases.
opcodes/
2020-07-14 Claudiu Zissulescu <claziss@gmail.com>
* arc-dis.c (print_insn_arc): Detect and emit a warning when a
faulty double register pair is detected.
binutils/
2020-07-14 Claudiu Zissulescu <claziss@gmail.com>
* testsuite/binutils-all/arc/double_regs.s: New test.
* testsuite/binutils-all/arc/objdump.exp: Add the above test.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
%db<n> is an AT&T invention; the Intel documentation and MASM have only
ever specified DRn (in line with CRn and TRn). (In principle gas also
shouldn't accept the names in Intel mode, but at least for now I've kept
things as they are. Perhaps as a first step this should just be warned
about.)
Rm (and hence OP_R()) can be dropped by making 'Z' force modrm.mod to 3
(for OP_E()) instead of ignoring it. While at it move 'Z' handling to
its designated place (after 'Y'; 'W' handling will be moved by a later
change).
Moves to/from TRn are illegal in 64-bit mode and thus get converted to
honor this at the same time (also getting them in line with moves
to/from CRn/DRn ModRM.mod handling wise). This then also frees up the L
macro.
Rdq, Rd, and MaskR can be replaced by Edq, Ed / Rm, and MaskE
respectively, as OP_R() doesn't enforce ModRM.mod == 3, and hence where
MOD matters but hasn't been decoded yet it needs to be anyway. (The case
of converting to Rm is temporary until a subsequent change.)
In this case there's no need to go through prefix_table[] at all - the
.prefix_requirement == PREFIX_OPCODE machinery takes care of this case
already.
A couple of further adjustments are needed though:
- Gv / Ev and alike then can't be used (needs to be Gdq / Edq instead),
- dq_mode and friends shouldn't lead to PREFIX_DATA getting set in
used_prefixes.
The only valid (embedded or explicit) prefix being the data size one
(which is a fairly common pattern), avoid going through prefix_table[].
Instead extend the "required prefix" logic to also handle PREFIX_DATA
alone in a table entry, now used to identify this case. This requires
moving the (adjusted) ->prefix_requirement logic ahead of the printing
of stray prefixes, as the latter needs to observe the new setting of
PREFIX_DATA in used_prefixes.
Also add PREFIX_OPCODE on related entries when previously there was
mistakenly no decode step through prefix_table[].
It was quite odd for the prior operand handling to have to clear this
flag for the actual operand handling to print nothing. Have the actual
operand handling determine whether the operand is actually present.
With this {d,q}_scalar_swap_mode become unused and hence also get dropped.
These are only used when VEX.L or EVEX.L'L have already been decoded,
and hence the "normal" length dependent name determination is quite
fine. Adjust a few enumerators to make clear that vex_len_table[] has
been consulted; be consistent and do so for all *f128 and *i128 insns
in one go.
Fold redundant case blocks and move the extra adjustments logic into
the single case block that actually needs it - there's no need to go
through the extra logic for all the other cases. Also utilize there that
vex.b cannot be set at this point, due to earlier logic. Reduce the
comment there, which was partly stale anyway.
Unlike the earlier ones these also need their operands adjusted. Replace
the (mis-described: there's nothing "scalar" here) {b,w}_scalar_mode by
a single new mode, with the actual unit width controlled by EVEX.W.
The operands don't allow disambiguating the insn in 64-bit mode, and
hence suffixes need to be emitted not just in AT&T mode. Achieve this
by re-using %LQ while dropping PCMPESTR_Fixup().
MOVBE_Fixup() is entirely redundant with the S macro already used on the
mnemonics, leading to double suffixes in suffix-always mode. Drop the
function.
Just like other insns with GPR operands, CRC32 with only register
operands should not get a suffix added unless in suffix-always mode.
Do away with CRC32_Fixup() altogether, using other more generic logic
instead.
Unlike for non-zero values passed to USED_REX(), where rex_used gets
updated only when the respective bit was actually set in the encoding,
zero getting passed in is not further guarded, yet such a (potentially
"empty") REX prefix takes effect only when there are registers numbered
4 and up.
There's only a very limited set of modes that this function gets invoked
with - avoid it being more generic than it needs to be. This may, down
the road, allow actually doing away with the function altogether.
This eliminates a first improperly used "USED_REX (0)".
While some insns support both XOP.W based operand swapping and 256-bit
operation (XOP.L=1), many others don't support one or both.
For {L,S}LWPCB also fix the so far not decoded ModRM.mod == 3
restriction.
Take the opportunity and replace the custom OP_LWP_E() and OP_LWPCB_E()
routines by suitable other, non-custom operanbd specifiers.
Just like other VEX-encoded scalar insns do.
Besides a testcase for this behavior also introduce one to verify that
XOP scalar insns don't honor -mavxscalar=256, as they don't ignore
XOP.L.
There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping and the printing of the remaining 4-bit
immediate. VEX.W can be handled just like 4-operand insns.
Also take the opportunity and drop the stray indirection through
vex_w_table[].
There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping. The latter can be easily integrated into
OP_REG_VexI4().
The unnecessary XOP.L decoding had caught my eye, together with the not
really expected operand specifiers. Drop this decode step, and instead
make sure XOP.W and XOP.PP don't get ignored. For the latter, do this in
a form applicable to all XOP insns, rather than adding extra table
layers - there are no encodings with the field non-zero. Besides these
two, for the scalar forms XOP.L actually needs to also be zero.
Since we have these macros, there's no point having unnecessary table
depth.
VFPCLASSP{S,D} are now the first instance of using two %-prefixed
macros, which has pointed out a problem with the implementation. Instead
of using custom code in various case blocks, do the macro accumulation
centralized at the top of the main loop of putop(), and zap the
accumulated macros at the bottom of that loop once it has been
processed.
For all of these only the 512-bit forms are valid, so drop 256-bit ones
from the integer insert/extract variants.
Also replace EXxmmq by the more natural (here) EXymm.
Just like their AVX counterparts do for VEX.L.
At this occasion also make EVEX.W have the same effect as VEX.W on the
printing of VPINSR{B,W}'s operands, bringing them also in sync with
VPEXTR{B,W}.
Unlike for the EVEX-encoded versions, the VEX ones failed to decode
VEX.W. Once the necessary adjustments are done, it becomes obvious that
the EVEX and VEX table entries for VCVTPS2PH are identical and can hence
be folded.
The duplication is not only space inefficient, but also risks entries
going out of sync (some of which that I became aware of while doing this
work will get addressed subsequently). Right here note that for
VGF2P8MULB this also addresses the prior lack of EVEX.W decoding (i.e. a
first example of out of sync entries).
This introduces EXxEVexR to some VEX templates, on the basis that this
operand is benign there and only relevant when EVEX encoding ends up
reaching these entries.
There's only a single user, that that one can do fine with the
alternative, as the "Vex" aspect of the other operand kind is meaningful
only on 3-operand insns.
While doing this I noticed that I didn't need to do the same adjustment
in the EVEX tables, and voilà - there was a bug, which gets fixed at the
same time (see the testsuite changes).
Along the lines of 4102be5cf9 ("x86: replace EXxmm_mdq by
EXVexWdqScalar"), but in the opposite direction, replace EXdScalar/
EXqScalar by EXxmm_md/EXxmm_mq respectively, rendering d_scalar_mode and
q_scalar_mode unused. The change is done this way to improve telling
apart operands affected here from ones using EXbScalar/EXwScalar, which
work sufficiently differently. Additionally this increases similarity
between several VEX-encoded insns and their EVEX-encoded counterparts.
We check register-only source operand to decide if two source operands of
VEX encoded instructions should be swapped. But source operands in AMX
instructions with two source operands swapped are all register-only
operand. Add SwapSources to indicate two source operands should be
swapped.
gas/
* config/tc-i386.c (build_modrm_byte): Check vexswapsources to
swap two source operands.
opcodes/
* i386-gen.c (opcode_modifiers): Add VexSwapSources.
* i386-opc.h (VexSwapSources): New.
(i386_opcode_modifier): Add vexswapsources.
* i386-opc.tbl: Add VexSwapSources to BMI2 and BMI instructions
with two source operands swapped.
* i386-tbl.h: Regenerated.
The unprivileged CSR should be controlled by other specific specs rather
than the privileged spec. For example, the debug CSR should be controlled
by the debug spec, and the float CSR should be controlled by the float
spec. User may use assembler options to choose what the debug and other
specs they want, or may encode the versions of specs into the architecture
string directly. Since we haven't decided which one is better, we set the
defined and aborted versions of unprivileged CSR to PRIV_SPEC_CLASS_NONE
in the include/opcode/riscv-opc.h, to tell assembler don't check priv spec
versions for them. However, these PRIV_SPEC_CLASS_NONE will be changed
to FLOAT_SPEC_CLASS_* and DEBUG_SPEC_CLASS_* in the future.
gas/
* config/tc-riscv.c (riscv_csr_class_check): Removed. Move the
checking into riscv_csr_address.
(riscv_csr_version_check): Likewise.
(riscv_csr_address): New function. Return the suitable CSR address
after checking the ISA dependency and versions. Issue warnings if
we find any conflict and -mcsr-check is set. CSR_CLASS_F and
CSR_CLASS_DEBUG are unprivileged CSR for now, so don't check the
priv spec versions for them.
(reg_csr_lookup_internal): Call riscv_csr_address to find the
suitable CSR address.
* testsuite/gas/riscv/priv-reg-fail-fext.d: Remove -mpriv-spec=1.11.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-fext.l: We don't care the
priv spec warnings here. These warnings are added by accident.
Remove them and only focus on the ISA dependency warnings.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p9.l: Updated since
dscratch0 and dscratch1 are regarded as the unprivileged CSR rather
than the privileged ones.
* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
* testsuite/gas/riscv/priv-reg.s: Likewise. Add missing debug CSR.
* testsuite/gas/riscv/priv-reg-version-1p9.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
include/
* opcode/riscv-opc.h: Support the unprivileged CSR. The versions
of the unprivileged CSR should be PRIV_SPEC_CLASS_NONE for now.
* opcode/riscv.h (enum riscv_csr_class): Add CSR_CLASS_DEBUG.
opcodes/
* riscv-dis.c (print_insn_args, case 'E'): Updated. Let the
unprivileged CSR can also be initialized.
