This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ENTER/BOUND operands order.
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "SÅawomir Wojtasiak" <slawomir dot wojtasiak at swksoftware dot pl>
- Cc: <hjl dot tools at gmail dot com>,<binutils at sourceware dot org>
- Date: Thu, 16 Jan 2014 08:20:37 +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>
>>> On 15.01.14 at 22:31, "Slawomir Wojtasiak" <slawomir.wojtasiak@swksoftware.pl> wrote:
> Dnia 2014-01-07 11:09 Jan Beulich napisaÅ(a):
>>In fact, the amount of inconsistencies appears to continuously
>>increase in particular with new SIMD additions, recently in bogus
>>operand swapping requiring to use an incorrect operand order
>>in Intel syntax:
>>
>> vcvtsi2ss xmm0, xmm0, {rn-sae}, eax
>> vcvtusi2ss xmm0, xmm0, {rn-sae}, eax
>>
>>(where in fact the rounding mode specifier ought to be the
>>last operand).
>
> Exactly, GAS can be at cutting edge of the AT&T dialect, but I'm pretty sure
> that it should strictly follow Intel dialect syntax, so encoding in the
> example above is probably a bug. These instructions are relatively new, so
> they probably will be fixed in near future. For instance I found a lot of
> broken SIMD/AVX instructions in GDB 7.1 last year and all of them have been
> already fixed in the current version of the GNU debugger (and the fact that
> they was shipped wasn't the problem), so we have to hope for the best ! :)
Except that fixing disassembler bugs (i.e. what affects gdb) of this
kind is always possible, whereas fixing assembler bugs isn't: People
may have written (wrong) code already that they expect to the
assembler to accept if it once did. I therefore understand H.J.'s
reservations here to a certain degree - but I nevertheless want the
assembler to strive towards accepting valid code and rejecting
broken stuff (the latter to reduce surprises when moving or reusing
code between different assemblers).
Jan