CGEN_DIS_HASH: how to get endianness and/or instruction size?

The ARCompact architecture has both 16 and 32 bit opcodes,
and each can
take an optional 32 bit immediate.  Moreover, this is a
bi-endian
architecture.
So, inside CGEN_DIS_HASH, how can I get the first 16 bits of
the instruction,
represented in host byte order?
If I want to dereference the buffer pointer, I need to know
the target
endianness.
If I want to use the passed instruction value, I need to
know what size it
is.  Note that there are valid 32 bit opcodes which have all
upper 16 bits
cleared.
It is also not quite clear if I can use this value if there
is a 32 bit
immediate attached to the opcode.

Hi -

On Thu, Jan 25, 2007 at 02:20:36PM +0000, Joern Rennecke
wrote:

> [...]  So, inside CGEN_DIS_HASH, how can I get the
first 16 bits of
> the instruction, represented in host byte order?

> If I want to dereference the buffer pointer, I need to
know the
> target endianness.

Use the "value" parameter (a host-endian copy of
the "base insn")
rather than the "buffer" parameter.

> If I want to use the passed instruction value, I need
to know what
> size it is.  [...]

See m32r_cgen_dis_hash: a hand-written baby insn classifier
routine.

It is important to realize though that this disassembler
hashing
widget is strictly an optimization.  You can try hard-coding
the hash
value to 0 like some other cgen platforms, and see if the
performance
is bearable.

- FChE

On Thu, Jan 25, 2007 at 09:59:50AM -0500, Frank Ch. Eigler
wrote:
> Use the "value" parameter (a host-endian copy
of the "base insn")
> rather than the "buffer" parameter.
> 
> > If I want to use the passed instruction value, I
need to know what
> > size it is.  [...]
> 
> See m32r_cgen_dis_hash: a hand-written baby insn
classifier routine.

I've seen that, but it assumes that if the top 16 its are
zero,
the instruction can be hashed as a 16 bit instruction.  That
is not
the case for ARCompact.
Branch Conditionally is a 32 bit instuction can have all the
top 16 bits
zeroed, and its bottom 16 bits are all operand.

> It is important to realize though that this
disassembler hashing
> widget is strictly an optimization.  You can try
hard-coding the hash
> value to 0 like some other cgen platforms, and see if
the performance
> is bearable.

I can only verify this positively when I've completely
finished the
port so that other people can use it...

Hi -

On Thu, Jan 25, 2007 at 08:30:11PM +0000, Joern Rennecke
wrote:
> I've seen that, but it assumes that if the top 16 its
are zero,
> the instruction can be hashed as a 16 bit instruction. 
That is not
> the case for ARCompact. [...]

Where are the bits that allow the insn to be decoded as a
branch?  How
the hardware know whether it's a 16- or 32-bit insn?  Those
are the
kind of bits are what are normally mingled into the hash. 
Maybe your
base_insn designation is too small.

> > It is important to realize though that this
disassembler hashing
> > widget is strictly an optimization.  [...]
> 
> I can only verify this positively when I've completely
finished the
> port so that other people can use it...

Indeed, but if you can accept a lesser standard of proof,
you could
leave this part of the port till the end.


- FChE