From: "Jan Beulich" <JBeulich@suse.com>
To: "Kirill Yukhin" <kirill.yukhin@gmail.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
"Binutils" <binutils@sourceware.org>,"H. Peter Anvin"
<hpa@zytor.com>
Subject: Re: [PATCH] x86/Intel: accept mandated operand order for vcvt{,u}si2s{d,s}
Date: Tue, 26 May 2015 08:04:00 -0000 [thread overview]
Message-ID: <55644524020000780007DB9A@mail.emea.novell.com> (raw)
In-Reply-To: <20150525145555.GA9967@msticlxl57.ims.intel.com>
>>> On 25.05.15 at 16:55, <kirill.yukhin@gmail.com> wrote:
> 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.
I'm confused - did you perhaps mean to say "I don't see any reason
not to introduce ..."?
Jan
next prev parent reply other threads:[~2015-05-26 8:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 14:16 Jan Beulich
2015-04-23 12:39 ` H.J. Lu
2015-04-23 13:06 ` Jan Beulich
2015-04-23 13:17 ` H.J. Lu
2015-04-23 13:48 ` Jan Beulich
2015-04-23 13:53 ` H.J. Lu
2015-05-05 16:07 ` Jan Beulich
2015-05-05 16:10 ` H.J. Lu
2015-05-06 7:44 ` Jan Beulich
2015-05-21 6:30 ` Jan Beulich
2015-05-21 10:42 ` H.J. Lu
2015-05-21 11:37 ` Jan Beulich
2015-05-21 12:07 ` H.J. Lu
2015-05-21 15:03 ` Jan Beulich
2015-05-21 15:12 ` H.J. Lu
2015-05-21 16:05 ` Jan Beulich
2015-05-25 14:56 ` Kirill Yukhin
2015-05-26 8:04 ` Jan Beulich [this message]
2015-05-26 11:25 ` Kirill Yukhin
2015-05-26 12:18 ` Jan Beulich
2015-06-01 9:17 ` Mark Wielaard
2015-06-01 9:23 ` Jan Beulich
2015-06-01 9:41 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55644524020000780007DB9A@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=kirill.yukhin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).