Re: ENTER/BOUND operands order.

[Michael Zolotukhin <michael dot v dot zolotukhin at gmail dot com>]

Hi Jan,

> 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).
Could you please point me to the MASM reference describing the case we are
talking about?  I looked at [1], but it lacks even 'ZMMWORD' keyword, so I
assumed that AVX-512 isn't supported there at all.  (I'm not a MASM expert, so
maybe I'm just looking at completely wrong place).

> 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).
That's not it.  Both ASM and objdump tables were generated automatically, and
the rounding/sae operand needed a special handling there.  This order was chosen
intentionally.
BTW, could you please report other mistakes you found?

[1] http://msdn.microsoft.com/en-us/library/8t163bt0.aspx

Michael
> Jan

On 17 January 2014 12:21, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 17.01.14 at 08:01, "Michael V. Zolotukhin" <michael.v.zolotukhin@gmail.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
>> 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.
>
> Jan
>



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.