x86 operand size overriding prefixes vs suffixes vs ambiguity warnings

[Jan Beulich]

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?

>> projects want to be able to be built with a relatively large
>> range of tool chain versions. As a result it is not clear to me
>> what specifically you mean with "We will change opcode map." Of
>> course new insns will get added. Do you have anything else in
>> mind here?
>>
>> Furthermore your response doesn't make me see what underlying
>> model you think of following, besides the one that you had
>> outlined and that I indicated I don#t think can be used.
> 
> I disagree.

I see. You didn't say why though, and hence I'm unable to follow
you. I did explain why I think the way I do...

Jan