From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111336 invoked by alias); 25 May 2015 14:56:20 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 111321 invoked by uid 89); 25 May 2015 14:56:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f170.google.com Received: from mail-yk0-f170.google.com (HELO mail-yk0-f170.google.com) (209.85.160.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 25 May 2015 14:56:09 +0000 Received: by ykfr66 with SMTP id r66so20918061ykf.0 for ; Mon, 25 May 2015 07:56:07 -0700 (PDT) X-Received: by 10.170.60.208 with SMTP id c199mr3308837ykc.72.1432565767835; Mon, 25 May 2015 07:56:07 -0700 (PDT) Received: from msticlxl57.ims.intel.com (fmdmzpr04-ext.fm.intel.com. [192.55.55.39]) by mx.google.com with ESMTPSA id c59sm9045776yhn.24.2015.05.25.07.56.05 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 May 2015 07:56:07 -0700 (PDT) Date: Mon, 25 May 2015 14:56:00 -0000 From: Kirill Yukhin To: Jan Beulich Cc: "H.J. Lu" , Binutils , "H. Peter Anvin" Subject: Re: [PATCH] x86/Intel: accept mandated operand order for vcvt{,u}si2s{d,s} Message-ID: <20150525145555.GA9967@msticlxl57.ims.intel.com> References: <552FE0630200007800072CD0@mail.emea.novell.com> <55390A6A0200007800075263@mail.emea.novell.com> <554906C70200007800076D28@mail.emea.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554906C70200007800076D28@mail.emea.novell.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00243.txt.bz2 Folks, On 05 May 17:07, Jan Beulich wrote: > >>> On 23.04.15 at 15:17, wrote: > > On Thu, Apr 23, 2015 at 6:06 AM, Jan Beulich wrote: > >>>>> On 23.04.15 at 14:39, wrote: > >>> On Thu, Apr 16, 2015 at 7:16 AM, Jan Beulich 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 > >>>> > >>>> * 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 > >>>> > >>>> * 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