This is the mail archive of the 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: ENTER/BOUND operands order.

>>> On 17.01.14 at 08:01, "Michael V. Zolotukhin" <> 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 
> modifier.
> 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 
> change
> it.  And even if it was committed yesterday, what would be a good reason to 
> just
> 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.


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