Re: readability improvements to i386-opc.tbl

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 15.11.17 at 14:22, <hjl.tools@gmail.com> wrote:
> On Wed, Nov 15, 2017 at 5:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.11.17 at 13:43, <hjl.tools@gmail.com> wrote:
>>> On Wed, Nov 15, 2017 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> H.J.,
>>>>
>>>> for a while I've been thinking about how to shrink some of the overly
>>>> long lines in that file, as that's imo severely hampering readability
>>>> (and hence maintainability). There are two pretty simple
>>>> adjustments I'd like to propose as at least a first step, but which I
>>>> wouldn't want to carry out without some prior agreement (as the
>>>> resulting patches would obviously be huge):
>>>>
>>>> 1) BaseIndex implies Disp{8,16,32,32S} (with a few MPX insn
>>>> exceptions, which aren't necessary as 16-bit addressing not being
>>>> legal for them is being dealt with in tc-i386.c explicitly anyway, in
>>>> md_assemble()). i386-gen could easily set those implied bits.
>>>>
>>>> 2) Many instructions allow no suffixes at all (in particular most of
>>>> the myriad of SIMD ones). Many other instructions allow just a
>>>> single suffix. I'd like to propose No_Suf to accompany No_*Suf
>>>> and {b,w,l,s,q,ld}Suf as the inverse of No_*Suf, to be used when
>>>> the list of permitted suffixes is shorter than the list of forbidden
>>>> ones. Again this could be dealt with in i386-gen relatively easily.
>>>>
>>>>
>>>
>>> They sound good.  Can you take a look at
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=20320 
>>>
>>> as the first step?
>>
>> I think I had looked at precisely that a few years back, finding a few
>> cases where there was no full equivalence. In any event the main
>> obstacle is the dual purpose use of the 'l' suffix for integer and FPU
>> insns. The other immediately obvious issue is with movzx (where
>> the suffix describes the destination operand size, but Byte refers
>> to the source operand).
> 
> Can we replace these specific cases with something else?

Not sure yet; this would certainly go beyond the mostly mechanical
work I was intending to do right away. But I may still consider doing
so in favor of 2) above, but likely after having done 1) (if that works
out in the first place).

Jan