Hi,

Currently insns are added to the chains of the hash table in the
disassembler in the order in which they appear in the .cpu file. Thus,
resolution of insns which are a special case of another must be
managed by carefully defining then in the correct order. The insns are
also parsed in the order in which they appear and this is important in
cases where an operand in the assembler input might be successfully
parsed as more than on ecgen operand (e.g. register names are
successfully parsed as immediates). There is an impass, however, when
the order in which insns need to be parsed is not the same as the
order in which decoding must be attempted.

I have run into such a case where an operand of an insn may be a
register name or an immediate. One particular register is forbidden,
however, and when the bits representing that register appear in the
field of the insn, it signifies that the operand is really an
immediate value which follows the insn. Thus the operand must be
parsed as a register name first, but decoding must attempt it as an
immediate first.

The problem may be solved by automating the order in which the insns
are placed into the hash chains in the disassembler. By ordering insns
iby the number of decoding bits in decreasing order, we can assure
that an insn which is a special case of another wil be attempted
first, regardless of the order in which they appear in the .cpu file.
This is the same ordering which would have been required manually up
until now, so no existing ports should be affected.

I have tested the attached patch on m32r (sid), fr30 and two internal
ports. Requesting approval to commit.

Dave