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

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

>>> On 01.07.16 at 15:58, <hjl.tools@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 6:29 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 01.07.16 at 14:38, <hjl.tools@gmail.com> wrote:
>>> On Fri, Jul 1, 2016 at 2:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> ... just like has been made the case recently for movzb and movzw.
>>>>
>>>> Note that this exposed a bug in check_qword_reg(): A missing 'r' (or
>>>> wrong 'e') register prefix needs to be complained about if the template
>>>> allows for a 64-bit register, not a 32-bit one. I assume this was a
>>>> copy-and-paste type of mistake (from check_long_reg()).
>>>>
>>>
>>> We don't support
>>>
>>>        movsl  %eax,%rax
>>>        movsl   (%rax),%rax
>>>
>>> today.
>>
>> Nor do we support (prior to this patch) the respective movsb and
>> movsw. Adding support for them (and then consistently, i.e.
>> including movsl) is the purpose of this patch.
>>
>>>  Remind me why we changed to support
>>>
>>>        movzl   %eax,%rax
>>>        movzl   (%rax),%rax
>>>
>>> There is no code outer there which uses this mnemonic.  Maybe it
>>> was a mistake to allow it.
>>
>> Where did you see this getting added?
> 
> 
> My mistake.   We shouldn't make "movsX" suffix-less since
> there are "movsX".

Wait, what? With the changes done yesterday, as you can see from
the patch, making both variants work is feasible and non-intrusive,
and hence should be done (as also just said in the other reply to
Jonas); I don't think the reason for these suffix less variants having
been unsupported go anywhere beyond no-one having cared to
make that work (and deal with the necessary disambiguation).

Please can we first of all aim at the assembler behaving predictably,
which among other things means for it to be consistent in what it
accepts and what it refuses? It was really this inconsistency here
which caught me in the Xen hypervisor project (of which I'm one of
the maintainers), prompting me to try to find a solution once I'd
have a few spare cycles. And I really had been afraid the solution
would be much more involved than it now turned out to be.

Jan