Re: readability improvements to i386-opc.tbl

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

On Sun, Dec 10, 2017 at 11:50 PM, 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've looked some more into what exceptions exist that would
> complicate achieving that goal:
>
> - register only insns (push, pop, inc, etc): Reg8 => Reg|Byte etc?
>   (could then be extended to also eliminate FloatReg, FloatAcc, RegXMM, RegYMM,
>   and RegZMM; in turn FirstXmm0 could become Acc|Xmmword)
> - lgdt etc, lds etc, far call/jmp: size != meaning of suffix
> - movs/movz: final suffix describes (register) destination
> - bound's memory operand is double the size of the register one
> - floating point: alternative sizes implied from 'l'
> - {,v}pinsrw allow l/q suffixes (but memory operand is 16 bits); oddly enough
>   the AVX512BW form as well as {,v]pinsr{b,d} and {,v}pextr{b,d} don't allow any
>   suffix, while the 0fc5 {,v}pextrw form again does (and again except for the
>   AVX512BW form).
> - {,v}cvt{,t}ss2si allow l/q suffixes (but memory operand is 32 bits)
> - {,v}cvt{,t}sd2si allow l/q suffixes (but memory operand is 64 bits)
>
> This is not necessarily an exhaustive list. I think that addressing
> the first item separately up front would be a useful thing anyway
> (with the general goal - as per the title of this thread - in mind), so
> unless you have a clear reason to object to such an approach I'll
> see to look into this. I would want to keep Reg* as shorthands for
> the new Reg|<width> construct, to further improve readability as
> well as to reduce the amount of change needed / wanted to
> i386-opc.tbl.

It sounds reasonable to me.

> Independently I'd like to have your opinion on said pinsrw/pextrw
> suffix inconsistencies: Is this really intended? If so, why? If not,
> which of the two possible ways should this be corrected (drop
> all suffix permissions, or add missing ones)?

pinsrw/pextrw are special cases.   SDM used to have

66 REX.W 0F C5 /r
ib

PEXTRW r64,
xmm, imm8

Extract the word specified by
imm8 from xmm and move it to
r64, bits 15-0. Zero-extend the
result.

But they have been removed since then.  Now SDM has

In 64-bit mode, VEX.W1 is ignored for VPEXTRW (similar to legacy
REX.W=1 prefix in PEXTRW)

So we could drop the lq suffix on them.  But assembler has to
allow them for backward compatibility.

Thanks.

-- 
H.J.