Re: [PATCH v2 5/9] x86: improve handling of insns with ambiguous operand sizes

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Nov 15, 2019 at 12:40 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.11.2019 20:16, H.J. Lu wrote:
> > On Thu, Nov 14, 2019 at 1:00 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 13.11.2019 22:12,  H.J. Lu  wrote:
> >>> What do you mean by improving AT&T syntax?  AT&T syntax has
> >>> many quirks.  We should leave them alone if we can.
> >>
> >> May I kindly ask you to read the description of this patch again.
> >> Current AT&T behavior is, as far as I'm concerned, intolerably
> >> dangerous (and in the course of putting together this change
> >> over the last couple of years it has helped point out actual
> >> mistakes in other projects that I've been building with early
> >> versions of this change in place).
> >>
> >
> > The default size is one of quirks.  Changing it can make previously
> > working assembly codes stop working.  If one is writing the new
> > assembly codes in AT&T syntax, she/he should avoid default size
> > when in doubt.   We can add a command-line switch to check these
> > quirks.
>
> I.e. you want to effectively tell people that PUSH/POP/PUSHF/POPF
> etc _have_ to have suffixes in AT&T mode? Personally I wouldn't

Only if it isn't intuitive for AT&T syntax.  In that case, we can add a
warning and even disallow it in a couple years.

> expect this to be well received - to me, the more suffixes can
> be omitted without risking wrong code generation, the better for
> readability. Arguably this may be influenced by me having grown
> up with Intel syntax, and hence considering suffixes to harm
> readability, but anyway.
>
> In any even - I'll see about finding time to investigate in how
> far I can sensibly avoid at least some of the DefaultSize
> additions.

Appreciated.  Thanks.

-- 
H.J.