Re: ENTER/BOUND operands order.

[Michael Zolotukhin <michael dot v dot zolotukhin at gmail dot com>]

> 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]
Great, thanks! I'll take a look.

Michael


On 17 January 2014 16:57, Jan Beulich <JBeulich@suse.com> wrote:
>>>> 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
>



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.