x86 operand size overriding prefixes vs suffixes vs ambiguity warnings

[Jan Beulich]

On 09.06.2020 16:05, H.J. Lu wrote:
> On Tue, Jun 9, 2020 at 6:56 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.06.2020 15:04, H.J. Lu wrote:
>>> On Tue, Jun 9, 2020 at 5:59 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 08.06.2020 18:25, H.J. Lu wrote:
>>>>> On Mon, Jun 8, 2020 at 6:07 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 08.06.2020 14:44, H.J. Lu wrote:
>>>>>>> On Mon, Jun 8, 2020 at 5:28 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> H.J.,
>>>>>>>>
>>>>>>>> the documentation of gas isn't really helpful in regards to what
>>>>>>>> to expect when using explicit prefixes. For example I consider
>>>>>>>>
>>>>>>>>         rex64 movl %eax, %eax
>>>>>>>>         data16 movl %eax, %eax
>>>>>>>>
>>>>>>>> sufficiently bogus that I would see at least a warning warranted.
>>>>>>>> Otoh Andrew validly points out that for e.g. lret the possible
>>>>>>>>
>>>>>>>>         rex64 lret
>>>>>>>>         data16 lret
>>>>>>>>
>>>>>>>> are sufficiently meaningful to perhaps even suppress the
>>>>>>>> ambiguity warning the suffix-less lret-s currently cause in
>>>>>>>> 64-bit mode. The question really is whether we could settle on
>>>>>>>> an abstract model from which the behavior becomes predictable
>>>>>>>> for a programmer. Of course a fundamental requirement I would
>>>>>>>> have to any such model is that it be consistent for all current
>>>>>>>> and future insns and that it preferably have as little quirks or
>>>>>>>> special cases as possible.
>>>>>>>>
>>>>>>>> If you (or anyone else on the list) have any thoughts or
>>>>>>>> opinions here, I'd appreciate if you could share them.
>>>>>>>>
>>>>>>>
>>>>>>> My takes on this are
>>>>>>>
>>>>>>> 1. If a prefix is totally ignored, assembler should allow it and
>>>>>>> disassembler should display it.  Such prefixes can be used for
>>>>>>> padding.
>>>>>>> 2. If a prefix changes the instruction behavior and there is no
>>>>>>> other ways to encode such instruction behavior, assembler
>>>>>>> should allow it and disassembler should display it.  Such
>>>>>>> prefixes can be used for valid operation.
>>>>>>> 3. Otherwise, if a prefix changes the instruction behavior,
>>>>>>> there should be an error, at least a warning.
>>>>>>
>>>>>> All of these are difficult when considering the evolving ISA:
>>>>>> What is "ignored" or "changing behavior" varies over time. To take
>>>>>> a concrete example, according to what you say WBNOINVD being a
>>>>>> prefixed version of WBINVD should have been accepted in the latter
>>>>>> form by gas prior to the addition of support for the insn, but not
>>>>>> anymore. That's not very nice for people using gas. And to preempt
>>>>>
>>>>> We will change opcode map.  The means of prefixes will change
>>>>> over time.  Programmers need to find a way to deal with it.  Assembler
>>>>> can help within reasonable limits.
>>>>
>>>> "Programmers need to find a way to deal with it" is particularly
>>>> relevant: Once they've found a means to encode an insn an older
>>>> version of gas doesn't support yet, newer versions of gas
>>>> shouldn't reject (nor even warn) about the encoding. Many (most?)
>>>
>>> I used the following options to deal such cases:
>>>
>>> 1. Use .byte to encode the whole instruction.
>>> 2. Use .byte to only encode prefix.
>>
>> If that's the model to use, what use are the prefix mnemonics then?
> 
> 1. Some prefixes won't change operations.
> 2. It is easier to write notrack than .byte.

notrack is a bad example, as it's tied to (and only permitted for)
a small set of insns. The rep forms would be of more interest, but
as said earlier they're also restricted in their use. The main
question here was about the data size overrides (66 and REX.W) as
well as the other rex forms, though.

> 3. The disassembler should always display the proper prefix which
> can be assembled.

Which can be assembled? I.e. you suggest disassembler output
should be (sufficiently) suitable for passing back into the
assembler? That's surely not the case for the rep forms.

Jan