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: ""H.J. Lu"" <hjl dot tools at gmail dot com>, binutils at sourceware dot org
- Date: Wed, 15 Jan 2014 22:31:39 +0100
- Subject: Re: ENTER/BOUND operands order.
- Authentication-results: sourceware.org; auth=none
- References: <3482868a668de8ebe53975eb7d79d725 dot qmail at home dot pl>
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