How does CGEN decide what ifields to use for CGEN_IVALUE?

[Dave Brolley]

Can you give an example of a set of insns with this problem? I's hard to 
help without seeing the specifics. In general, I've found that 
disassembly problems are usuallu due to incompletely specified insns, 
i.e. not all bits are completely specified in the .cpu file.

Dave

John Stubley wrote:
> Hi,
>
> I am writing a binutils port for our own internal proprietary CPU using
> CGEN.  I am using binutils v2.19 stable and cgen monthly snapshot
> 20081101.
>
> I am seeing some odd behaviour in the disassembly shown by objdump when
> it is analysing the opcodes I am generating using GAS.  In some cases,
> if I change the value of an operand I can cause the disassembler to fail
> to recognise the opcode.
>
> Our instruction packing is quite tight and so some of the operand fields
> overlap with some of the opcode mnemonic fields.  I have tried to define
> the instruction families so that they don't overlap, but I can't quite
> do it.  Ideally, I would like to teach CGEN a simple hierarchy of
> mnemonics so that it can order the opcode table correctly.  However, it
> appears at first instance that there is no way to write the .cpu file to
> give CGEN enough hints.  I assume it has something to do with the
> CGEN_OPCODE_* macros for CGEN_IVALUE in cgen.h.  I have tried setting
> the decode-assist in the define-isa, but this appears to have no effect.
>
> I would appreciate any pointers that you could give me, particularly if
> there is an existing CPU that attempts something similar.
>
> With thanks,
>
> John Stubley
> Development Engineer
> DisplayLink (UK) Limited
>
>