Home Original page

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

Jan Beulich JBeulich@suse.com
Tue May 5 16:07:00 GMT 2015 
>>> 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
More information about the Binutils mailing list