This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN 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]

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


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