This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
How does CGEN decide what ifields to use for CGEN_IVALUE?
- From: "John Stubley" <john dot stubley at displaylink dot com>
- To: <cgen at sources dot redhat dot com>
- Date: Wed, 14 Jan 2009 17:09:10 -0000
- Subject: How does CGEN decide what ifields to use for CGEN_IVALUE?
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