This is the mail archive of the
mailing list for the binutils project.
Re: ENTER/BOUND operands order.
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>, "S??awomir Wojtasiak" <slawomir dot wojtasiak at swksoftware dot pl>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Fri, 17 Jan 2014 08:21:02 +0000
- Subject: Re: ENTER/BOUND operands order.
- Authentication-results: sourceware.org; auth=none
- References: <3482868a668de8ebe53975eb7d79d725 dot qmail at home dot pl> <b4fcb2a62aa358bc134689ccd33eebcb dot qmail at home dot pl> <52D7A465020000780011423E at nat28 dot tlf dot novell dot com> <CANtU078BKxoUiKdmqp8ii0TFvi2T1itzzn7dicQoAbKzdwtRmg at mail dot gmail dot com> <52D807FE02000078001144A2 at nat28 dot tlf dot novell dot com> <CANtU07-s=VXv2yCb2FA_Dyco14d5LiC4of7r7zCkNa+4_omFxg at mail dot gmail dot com> <52D80C8402000078001144D5 at nat28 dot tlf dot novell dot com> <9f1ffd59bc7111c4ba411898a840f1c6 dot qmail at home dot pl> <20140117070150 dot GA13904 at msticlxl57 dot ims dot intel dot com>
>>> On 17.01.14 at 08:01, "Michael V. Zolotukhin" <email@example.com> wrote:
>> Unfortunately as Jan said, these instructions seem to be broken. Intel
>> manual is pretty accurate about the syntax of EVEX-encoded instructions.
>> Unit tests can not prove anything in this specific case. Opmask registers as
>> well as EVEX flags are encoded using these braces located directly next to
>> the instruction operands.
> That's not it. As I said, the document only expresses required elements
> that an
> assembler could implement. Whether to treat it as an ASM syntax operand is
> purely a SW tool implementation choice, as is the placement of such a
> How a parser chooses to accept token definitions for this element is another
> implementation detail for the tool implementer and doesn't belong in this
> document. That's almost a quote from the document's author.
> Thus, order of operands is implementation dependent, and for GAS it is the
> following: RC/SAE operand goes between SIMD-operand and non-SIMD operand (or
> after SIMD-operand if there is no non-SIMD one). That was suggested when the
> patch was sent (in July'13), and there were no objections to it. Now it is
> already in binutils 2.24, and there is nor reason neither possibility to
> it. And even if it was committed yesterday, what would be a good reason to
> reorder operands?
The fundamental reason is MASM compatibility. Irrespective of what
you said earlier, MASM has to be treated as the reference
implementation for Intel syntax. As much as I would think nowadays
GAS is the AT&T syntax reference implementation (even if - see the
context within this hole thread started - lack of care in how newer
instructions got handled put this under question).
As to "no objections" - I don't think it is reasonable to have gone
through the huge new test cases line by line to spot such oddities.
Furthermore, along with spotting these I also spotted other
mistakes heavily suggesting that the expected output was just
taken verbatim from what objdump produced, without checking
whether that output matched up with the input (i.e. what is there
could be there intentionally, but it could also just happen to be
that way). I'm slowly getting through fixing those issues, and will
eventually submit patches. This became reasonably possible only
after I got my own disassembler to support these newer
instructions, thus allowing me to compare the outputs rather than
going through the test cases line by line.
H.J. - I'm very surprised you as the maintainer of the code didn't
voice any opinion here so far.