x86 operand size overriding prefixes vs suffixes vs ambiguity warnings

[Jan Beulich]

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?)
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.

Jan