This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Folks,

On 05 May 17:07, Jan Beulich wrote:
> >>> 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?
Wanted to mention couple of points:
  1. I agree w/ HJ: SDM is not a source of syntax
  2. We have two product already released: ICC (2 version at the moment) and GCC
  (4.9 and 5) which use existing syntax for emitting those insns

Said that, I don't see any reason to introduce (not replace) alternative operand order.

--
Thanks, K


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]