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 Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "S??awomir Wojtasiak" <slawomir dot wojtasiak at swksoftware dot pl>
- Date: Fri, 17 Jan 2014 09:49:46 +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> <52D8F5FE020000780011470A at nat28 dot tlf dot novell dot com> <CANtU079-g7dcZV8WxkOOUNqRwD0RJu1tTqA5rUxwEaLx4SmktQ at mail dot gmail dot com>
>>> On 17.01.14 at 09:36, Michael Zolotukhin <email@example.com> wrote:
>> 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 , 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).
I said this in an earlier reply - I have no such reference, but I'm
sure this is at least in the works at Microsoft.
>> 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,
> the rounding/sae operand needed a special handling there. This order was
> BTW, could you please report other mistakes you found?
As said, I'll do so once I have fixes available.