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

[H.J. Lu]

On Mon, Jul 4, 2016 at 9:15 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.07.16 at 18:07, <hjl.tools@gmail.com> wrote:
>> On Mon, Jul 4, 2016 at 1:07 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 01.07.16 at 17:20, <jonas-devlists@watlock.be> wrote:
>>>
>>>> Jan Beulich wrote on Fri, 01 Jul 2016:
>>>>
>>>>>>>> On 01.07.16 at 16:24, <jonas-devlists@watlock.be> wrote:
>>>>>> 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.
>>>>>
>>>>> Well, the document referenced is a random one; it's way too new
>>>>> to be a canonical reference.
>>>>
>>>> I disagree that (originally) Sun documentation is a random reference
>>>> in the context of AT&T/System V UNIX. Yes, SVR4.2 i386 documentation
>>>> would be even better (if it mentions this issue), but I guess that
>>>> only exists as hard copy in someone's basement.
>>>>
>>>>> I do not understand what inconsistency you refer to here. The
>>>>> only inconsistency I can see is that one can't omit the suffixes
>>>>> from these three instructions, unlike any others with GPR
>>>>> operands.
>>>>
>>>> It is not consistent that all base mnemonics (i.e., without size
>>>> suffix) refer to individual opcodes (or groups of opcodes) as defined
>>>> in Intel's architecture manuals, except for movsb/w/l.
>>>
>>> I don't see what's wrong with this, when it's okay for the assembler
>>> to accept all kinds on non-AT&T syntax instructions in AT&T mode.
>>> Note how, for example, both movsx and movzx have specific AT&T
>>> entries despite these being Intel syntax mnemonics.
>>
>> Those are for historical reasons.  We shouldn't add new ones when
>> they buy nothing for programmers.
>
> Well, in the case here the addition does buy something for
> programmers, or else I wouldn't have stumbled into this mess. So
> I guess you only mean certain programmers, and I'm not one of
> them...
>

Existing AT&T mnemonic works for assembly codes.  We don't
add a new mnemonic just because it looks nicer.  Assembly codes
never look nice to me :-).

-- 
H.J.