Re: readability improvements to i386-opc.tbl

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

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?

-- 
H.J.