Re: [PATCH] x86: allow suffix-less sign-extending movsb, movsw, and movsl

[Jonas Maebe <jonas-devlists at watlock dot be>]

Jan Beulich wrote on Fri, 01 Jul 2016:

> > > > On 01.07.16 at 15:43, <jonas-devlists@watlock.be> wrote:
>
> > I think that is a really bad idea. movsb, movsw and movsl are existing
> > mnemonics for completely different opcodes (as in "rep movsb"). It
> > also seems to be against the spirit of AT&T syntax, which normally
> > requires you to explicitly specify all operand sizes fully with the
> > mnemonic in all cases, even if the assembler could in theory deduce
> > them from the operands.
>
> Where's that written down please?

In all honsesty, it's how I had always understood AT&T syntax to be,  
and the inline assembler parser in our compiler (which I did not  
write) also requires it. I had absolutely no idea until a few days ago  
there were AT&T syntax assembler parsers that allow you to omit size  
suffixes.

Looking for a reference, the most official/complete one I could find  
is http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf . And  
that one indeed states "If a mnemonic is specified with no type  
suffix, the operand
type defaults to long".

> As said in the movz patch
> description yesterday, movz{b,w} and movs{b,w,l} really are
> the odd ones - everything else gets accepted without suffixes when
> they're deducible from operands.

Referring again to the above document, it says about movsb/movsw:  
"movsb is not movsb{wlq}" and "movsw
is not movsw{lq}" (on p. 37). Those are the only mnemonics that are  
singled out in this way.

So in the end, I guess the movzb/movzw change is fine, but this one is  
not. It's in inherent inconsistency related to the ability of leaving  
away the size suffixes in combination with the chosen mnemonics, it  
seems. That in turn reinforces my opinion (which is clearly just that,  
rather than a universal rule) that you should always use size suffixes  
with AT&T syntax.


Jonas