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

[Jan Beulich <jbeulich@suse.com>]

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.

Jan