[PATCH 5/7] x86: re-work insn/suffix recognition

[H.J. Lu]

On Wed, Sep 7, 2022 at 12:17 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.09.2022 23:53, H.J. Lu wrote:
> > On Mon, Sep 5, 2022 at 11:40 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 26.08.2022 20:46, H.J. Lu wrote:
> >>> On Fri, Aug 26, 2022 at 2:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 23.08.2022 04:00, H.J. Lu wrote:
> >>>>> On Fri, Aug 19, 2022 at 1:28 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 18.08.2022 17:14, H.J. Lu wrote:
> >>>>>>> On Wed, Aug 17, 2022 at 11:24 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 17.08.2022 22:29, H.J. Lu wrote:
> >>>>>>>>> On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> x86: re-work insn/suffix recognition
> >>>>>>>>>>
> >>>>>>>>>> Having templates with a suffix explicitly present has always been
> >>>>>>>>>> quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
> >>>>>>>>>
> >>>>>>>>> I don't like the second pass.   What problem does it solve?
> >>>>>>>>
> >>>>>>>> It addresses the reasons we have various pretty odd (and confusing by
> >>>>>>>> their mere presence) insn templates which better would never have been
> >>>>>>>> there. If you have a better suggestion to eliminate those, I'm all ears.
> >>>>>>>>
> >>>>>>>> You can also easily see the issues this solves by looking at the
> >>>>>>>> testsuite changes. Among other things this once again is a matter of
> >>>>>>>> providing consistent and hence predictable behavior.
> >>>>>>>
> >>>>>>> Did you mean the error reporting behavior?  I don't think we should add
> >>>>>>> a second pass just for it.
> >>>>>>
> >>>>>> No. Certain insns simply were not accepted previously (this is actually
> >>>>>> what finally made me think of a solution here; prior observations
> >>>>>> weren't severe enough to try to get past your possible opposition which
> >>>>>> was to be expected based on past discussions). And certain other ones
> >>>>>> were wrongly accepted.
> >>>>>
> >>>>> Please open bug reports for these cases.
> >>>>
> >>>> PR gas/29524
> >>>> PR gas/29525
> >>>> PR gas/29526
> >>>>
> >>>> But really - what's the point of making me waste time on creating bug
> >>>> reports when fixes are already available?
> >>>
> >>> I don't see them as real issues and we shouldn't make assembler
> >>> more complex because of them.
> >>
> >> I sincerely disagree. As said many times - first and foremost the assembler
> >> should behave _consistently_. People should be able to predict behavior for
> >> one insn by knowing what the behavior is for sufficiently similar insns,
> >> without - as is the case twice here - having to further consider anomalies
> >> resulting from _dissimilar_ insns.
> >
> > Assembler should be consistent with x86 SDM and the existing usage.
> > Due to the history/nature of AT&T syntax and x86 instructions, there are
> > existing inconsistencies.  I don't think we should issue a warning for cmpsd.
> > It is inconsistent with the 'd' suffix instead of 'l'.  But it is
> > consistent with SDM.
> > What I'd like to see in mnemonics:
> >
> > 1. They are as close to SDM as possible.
>
> I.e. you want to add support for SCASD and alike? I doubt that was ever
> intended with AT&T syntax; instead divergence from Intel documentation
> was intentional from all I can tell.
>
> > 2. Allow prefix when there is an ambiguity.
> > 3. Intel syntax shouldn't depend on prefixes
>
> DYM "suffix" instead of "prefix" in these two? Assuming so, for 2) it
> ought to be "require", not "allow", and for 3) you certainly mean to
> allow for exceptions where the SDM has such (e.g. IRETD) or implies
> such (e.g. RETD) for there not being other ways to express operand
> size (within SDM nomenclature).
>
> As to IRETD - note how the SDM unhelpfully implies IRET to mean IRETW.
> We can't follow that doc to the word because of its own inconsistencies
> and/or shortcomings.
>

Sorry for the delay.  I was on vacation.  My main concern is to call
strdup and free for each instruction.   I prefer to add new entries to
deal with rare cases instead of penalizing all instructions.

-- 
H.J.