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.


Dnia 2014-01-07 11:09 Jan Beulich napisaÅ(a):
>>>> On 04.01.14 at 20:28, "Slawomir Wojtasiak" 
>wrote:
>> Hello everyone,
>> 
>> AT&T dialect says, that every instruction has opposite order of 
destination 
>> and source operands in comparison to the Intel syntax. So in fact, all 
>> operands are just inverted. Recently, I found out that there are at last 
two 
>> 
>> instructions (bound and enter) which seem not to follow the rule. 
Following 
>> example shows how they are currently encoded in GAS/Intel assembler:
>> 
>> INTEL: 62 30     bound esi,[eax]
>> GAS:   62 30     bound %esi,(%eax)
>> 
>> INTEL: c8 ee ff 01    enter 0ffeeh,01h
>> GAS:   c8 ee ff 01    enter $0xffee,$0x1
>>        c8 ee ff 55    enter $0xffee,$0x55
>>        
>> As you can see, both of these instructions have the same order of the 
>> operands. At first, I though that the fact that they do not have 
destination 
>> 
>> operand might be the case, but there are other similar instructions like 
>> "maskmovdqu" that follows the rule, so it looks like inconsistency. I 
>> haven't found any logical explanation yet, so I would be really grateful
>> for any information about this issue. Maybe this is expected behaviour 
(just 
>> an exception), or maybe a kind of historical reason?
>
>Indeed, and I have been pointing this out before (iirc for e.g.
>MONITOR/MWAIT in the forms that take operands). This is
>annoying and inconsistent, yet H.J. seems to advocate keeping
>it the way it is because assembler versions with the broken
>behavior got shipped.

Yes you're right MONITOR is also affected, I've forgotten about this one. 
Fortunately for all practical purposes GAS is an reference implementation of 
AT&T dialect, so with this knowledge I can continue to work on my own AT&T 
dialect implementation. I will treat these instructions just as exceptions 
to the general rule. 

>
>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).
>
>Jan
>
>

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 ! :)

Thanks for the information.
Slawomir Wojtasiak

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