This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ENTER/BOUND operands order.
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Michael Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "S??awomir Wojtasiak" <slawomir dot wojtasiak at swksoftware dot pl>
- Date: Fri, 17 Jan 2014 12:57:40 +0000
- Subject: Re: ENTER/BOUND operands order.
- Authentication-results: sourceware.org; auth=none
- References: <3482868a668de8ebe53975eb7d79d725 dot qmail at home dot pl> <b4fcb2a62aa358bc134689ccd33eebcb dot qmail at home dot pl> <52D7A465020000780011423E at nat28 dot tlf dot novell dot com> <CANtU078BKxoUiKdmqp8ii0TFvi2T1itzzn7dicQoAbKzdwtRmg at mail dot gmail dot com> <52D807FE02000078001144A2 at nat28 dot tlf dot novell dot com> <CANtU07-s=VXv2yCb2FA_Dyco14d5LiC4of7r7zCkNa+4_omFxg at mail dot gmail dot com> <52D80C8402000078001144D5 at nat28 dot tlf dot novell dot com> <9f1ffd59bc7111c4ba411898a840f1c6 dot qmail at home dot pl> <20140117070150 dot GA13904 at msticlxl57 dot ims dot intel dot com> <52D8F5FE020000780011470A at nat28 dot tlf dot novell dot com> <CANtU079-g7dcZV8WxkOOUNqRwD0RJu1tTqA5rUxwEaLx4SmktQ at mail dot gmail dot com> <52D90ACA02000078001147A1 at nat28 dot tlf dot novell dot com> <CANtU078QUocaPa9YsNUTrUaRW10xKDx99FJ8LBdFVgAZ_ooG=Q at mail dot gmail dot com>
>>> On 17.01.14 at 12:35, Michael Zolotukhin <michael.v.zolotukhin@gmail.com> wrote:
>> I said this in an earlier reply - I have no such reference, but I'm
>> sure this is at least in the works at Microsoft.
> In this case this doesn't look like a GAS error at all. Currently
> there are no other options, so the current GAS version (as it's
> already in product branches) should be taken as a reference.
>
>> As said, I'll do so once I have fixes available.
> Ok, thanks. I'd be glad to help fixing any issues with the new
> instructions, so please don't hesitate to simply report them.
If you can make sense of this
.text
avx512:
.intel_syntax noprefix
# Misplaced rounding identifiers (belong after eax); similar in disassembler
vcvtsi2ss xmm0, xmm0, {rn-sae}, eax
vcvtusi2ss xmm0, xmm0, {rn-sae}, eax
# Disp8 scaled by 8 rather than 4
vpmuldq zmm0, zmm0, [edx+4]{1to8}
vpmuldq zmm0, zmm0, [edx+8]{1to8}
vpmuludq zmm0, zmm0, [edx+4]{1to8}
vpmuludq zmm0, zmm0, [edx+8]{1to8}
# Disp8 disassembly scaled by 8 rather than 4
vgatherqps ymm1{k1}, [eax+zmm0+4]
vpgatherqd ymm1{k1}, [eax+zmm0+4]
vpscatterqd [eax+zmm0+4]{k1}, ymm0
vscatterqps [eax+zmm0+4]{k1}, ymm0
# destination and index the same being accepted
vgatherqps ymm0{k1}, [eax+zmm0]
vpgatherqd ymm0{k1}, [eax+zmm0]
- I don't have the time right now to go into much detail here, not
to speak of enter bugs. The disassembly issue I have a 2.24-based
fix for:
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -14196,13 +14197,11 @@ OP_E_memory (int bytemode, int sizeflag)
switch (bytemode)
{
case vex_vsib_d_w_dq_mode:
+ case vex_vsib_q_w_dq_mode:
case evex_x_gscat_mode:
case xmm_mdq_mode:
shift = vex.w ? 3 : 2;
break;
- case vex_vsib_q_w_dq_mode:
- shift = 3;
- break;
case x_mode:
case evex_half_bcst_xmmq_mode:
if (vex.b)
Of course that also requires testsuite adjustments, and I didn't get
around to do and test all this on master yet.
> As for the case with BOUND/ENTER - it really looks strange, but I
> suppose it's some kind of historic legacy, and it's too late to change
> it now.
You seem to still not fully understand: BOUND/ENTER are the ones
that are correctly handled. Other (newer) instructions with only (or
multiple) source operands are the ones where sloppiness in coding/
understanding lead to inconsistent behavior.
Jan