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: [PATCH] x86: allow suffix-less sign-extending movsb, movsw, and movsl


On Fri, Jul 1, 2016 at 7:24 AM, Jonas Maebe <jonas-devlists@watlock.be> wrote:
>
> 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.
>

I agree.

-- 
H.J.


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