Re: ENTER/BOUND operands order.

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 04.01.14 at 20:28, "Slawomir Wojtasiak" <slawomir.wojtasiak@swksoftware.pl>
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.

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