This is the mail archive of the binutils@sourceware.org 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 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


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