This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ENTER/BOUND operands order.
- From: "SÅawomir Wojtasiak" <slawomir dot wojtasiak at swksoftware dot pl>
- To: ""Jan Beulich"" <jbeulich at suse dot com>
- Cc: hjl dot tools at gmail dot com, binutils at sourceware dot org
- Date: Thu, 16 Jan 2014 21:56:55 +0100
- 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>
Dnia 2014-01-16 09:20 Jan Beulich napisaÅ(a):
>>>> 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
>
Unfortunately I didn't check these instructions with corresponding version
of GNU assembler, so I don't know if they were also broken or not. Anyway,
of course I agree with you that such bug fixes are always problematic,
nevertheless I think that it's the last chance to fix them without big
consequences. Intel dialect is probably not so widely used as AT&T is in
case of GAS and these instructions aren't very popular yet, so it should not
make a big mess.
SÅawomir Wojtasiak