This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: readability improvements to i386-opc.tbl


>>> 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).

I therefore think this isn't really viable.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]