[PATCH] x86/Intel: accept mandated operand order for vcvt{,u}si2s{d,s}

[Jan Beulich]

>>> On 23.04.15 at 15:17, <hjl.tools@gmail.com> wrote:
> On Thu, Apr 23, 2015 at 6:06 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.04.15 at 14:39, <hjl.tools@gmail.com> wrote:
>>> On Thu, Apr 16, 2015 at 7:16 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> As pointed out before, the documentation mandates the rounding mode to
>>>> follow the GPR, so gas should accept such input. As the brojen code got
>>>> released already we sadly will need to continue to also accept the
>>>> badly ordered operands.
>>>>
>>>> gas/testsuite/
>>>> 2015-04-16  Jan Beulich  <jbeulich@suse.com>
>>>>
>>>>         * gas/i386/avx512f-intel.d: Adjust expectations on operand order.
>>>>         * gas/i386/evex-lig256-intel.d: Likewise.
>>>>         * gas/i386/evex-lig512-intel.d: Likewise.
>>>>         * gas/i386/x86-64-avx512f-intel.d: Likewise.
>>>>         * gas/i386/x86-64-evex-lig256-intel.d: Likewise.
>>>>         * gas/i386/x86-64-evex-lig512-intel.d: Likewise.
>>>>
>>>> opcodes/
>>>> 2015-04-16  Jan Beulich  <jbeulich@suse.com>
>>>>
>>>>         * i386-opc.tbl: New IntelSyntax entries for vcvt{,u}si2s{d,s}.
>>>>         * i386-tbl.h: Regenerate.
>>>>
>>>
>>> I checked with our people.   Intel Software Developer Manual only governs
>>> the output side of the binary form of instruction byte stream matches what
>>> HW expect. Each assembly tool product has its own implementation of
>>> transforming the input language/dialect into the output stream.  In case of
>>> GNU assembler, operand order for AT&T and Intel syntax for AVX512 is
>>> the one used in AVX512 testcases.
>>
>> I don't mind AT&T being broken here (and elsewhere when it
>> comes to multiple source operands, as pointed out before), but
>> I do care about Intel syntax being in line with what the Intel
>> SDM says (and what I assume MASM is [going to] use). So
>> unless you're trying to tell me that the SDM is going to be
>> changed, or you have proof that MASM also deviates from what
>> the current documentation mandates ...
> 
>>> It is not OK.
>>
>> ... I guess as the Intel syntax maintainer I could decide to ignore
>> this.
> 
> MASM AVX512 compatibility isn't our goal.  Compatible with NASM is
> a good ideal.  Peter, Kirill, let's work it out.
> 
> Adding Peter for NASM and Kirill for GAS.

Not having seen any response from them at all, I think applying
at least the assembler side (which leaves the current bogus
operand order available) should really not be controversial. As
to the disassembler side, I continue to think that Intel syntax
disassembly should preferably match the Intel manual, especially
when there is no other implementation to use as reference.

Thoughts?

Thanks, Jan