This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
RE: Disassembly of instruction with 4 bit opcode
- From: "Michael Chapman" <Michael dot Chapman at synopsys dot com>
- To: "Ben Elliston" <bje at redhat dot com>,"Michael Chapman" <Michael dot Chapman at synopsys dot COM>
- Cc: <cgen at sources dot redhat dot com>
- Date: Mon, 4 Nov 2002 15:24:21 +0100
- Subject: RE: Disassembly of instruction with 4 bit opcode
Hi Ben,
What worked for me was:-
/* Override disassembly hashing - there are variable bits in the top
byte of these instructions. */
#define CGEN_DIS_HASH_SIZE 16
#define CGEN_DIS_HASH(buf,value) ((* (unsigned char*) (buf)) & 0x0f)
However, presumably it would be more efficient to make this a bit
more intelligent and only mask out the rest of the opcode in the
case that the 4 LSB bits are 0xc.
Regards,
Mike Chapman
-----Original Message-----
From: bje@scooby.brisbane.redhat.com
[mailto:bje@scooby.brisbane.redhat.com]On Behalf Of Ben Elliston
Sent: Monday, 04 November, 2002 13:33
To: Michael Chapman
Cc: cgen@sources.redhat.com
Subject: Re: Disassembly of instruction with 4 bit opcode
Hi Michael,
>>>>> "Michael" == Michael Chapman <Michael.Chapman@synopsys.com> writes:
Michael> The problem is with the "call" instructions which use only
Michael> 4 bits of the opcode using the remained for the address.
Michael> Everything is strictly little endian with the opcode always
Michael> appearing in the least significant 8 bits (or 4 bits in the
Michael> case of call) of the instruction. When I dissassemble the
Michael> following (listing output from the assembler)
[...]
Michael> 10: cc 00 *unknown*
Investigate using something like this in your <arch>.opc file:
/* Override disassembly hashing - there are variable bits in the top
byte of these instructions. */
#define CGEN_DIS_HASH_SIZE 8
#define CGEN_DIS_HASH(buf,value) (((* (unsigned char*) (buf)) >> 5) %
CGEN_DIS_HASH_SIZE)
Cheers, Ben