This is the mail archive of the binutils@sources.redhat.com 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]

NEC 5400 opcodes entries...


Richard, Eric,

I just noticed some of the changes in the recent addition of the NEC
5400 opcodes.

lots of stuff in the opcode table like:

{"add.ob",  "D,S,T",    0x4ac0000b, 0xffe0003f, WR_D|RD_S|RD_T,         N54     },
{"add.ob",  "D,S,T[e]", 0x4800000b, 0xfe20003f, WR_D|RD_S|RD_T,         N54     },
{"add.ob",  "D,S,k",    0x4bc0000b, 0xffe0003f, WR_D|RD_S|RD_T,         N54     },

When adding MDMX support, I added a 'Q' specifier which takes care of
all three of those cases (i.e., T, T[e], and k).  The bits appear to
be in the same position, and indeed in our own private implementation
of 5400 support we used 'Q' exclusively.  (I didn't submit it back
because, well, talking to Eric i knew you folks were going to submit
something back eventually, and I didn't want to cause you the merge
hassle or make myself the de-facto maintainer of "things 5400" by
getting there first.  8-)

Also, the MDMX code added "O", which has the same purpose as the
newly-added "%".

(also, i dunno whether the NEC documentation supports mention of those
opcodes w/ $vN as register numbers.  If so, should be using X,Y,
rather than D,S i believe.)


Using the existing operand types gets rid of some unnecessary code,
and a whole bunch of unnecessary opcodes lines.



chris


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