x86 operand size overriding prefixes vs suffixes vs ambiguity warnings

[H.J. Lu]

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.

> you pointing out that for older hardware the prefix keeps the insn
> as WBINVD, i.e. the added prefix is sufficiently benign, consider
> the move from MOVAPS to MOVAPD or basically any other insn where
> the later addition of prefixes altered insn behavior in not fully
> compatible ways. (The SDM spelling out where 66/F3/F2 are not
> allowed is a relatively recent addition, and neither fully
> consistent yet nor [yet] followed by AMD's PM.)

SDM improves overtime as you have observed.

> Therefore I don't think criteria like the ones you name can be
> used. Instead the decision could be tied to the kinds of operands
> an insn accepts and/or were given by the programmer. To just take
> the two examples given in my initial inquiry, just like suffix
> checking, prefixes could also be checked to be consistent with
> register operands provided. But maybe there are other way to
> abstract this.
>
> But of course any additional checking to be added bears the risk
> of closing avenues of what you describe as "Such prefixes can be
> used for valid operation."
>
> Additionally, unlike 66 and REX, the two REP prefixes are pretty
> strictly forbidden for almost any insn, due to the RepPrefixOk
> attribute. This is contrary to your "Such prefixes can be used
> for valid operation," making people fall back to using .byte
> instead.
>
> Jan



-- 
H.J.