From: Frank Ch. Eigler
>Hi -
Hi.
>Where are the bits that allow the insn to be decoded as
a branch?
There are lots of different branch patterns; for this
particular one,
we have to check that the top 5 bits and the lowest bit of
the first
16-bit word are zero.
(The actual data size in memory is likely different, but
from a tools
standpoint it is easiest to think of the instructions as a
succession
of 16 bit words. The bytes within the 16 bit words are
ordered according
to target endianness.
OTOH the manual uses insn-lsb0 #t, and describes 32 bit
opcodes as 32 bit words.
According to a comment in sh.cpu, cgen does not support
insn-lsb0 #t with
variable instruction length, so I have to translate all the
bit numbers...)
>How the hardware know whether it's a 16- or 32-bit
insn?
The top 5 bits of the first 16 bit word are what is known as
major
opcode field. The top three bits of these determine if the
opcode
is 16 bit, 32 bit, or if the encoding is reserved.
(However, a 16 or 32 bit opcode does not necessarily equate
to a 16
respective 32 bit instruction. When the number 62 is
encoded in a six bit
register operand field, that means that a 32 bit immediate
value is
used by this instruction, and that that immediate value is
used by all
operands which have 62 encoded in their 6 bit register
field.)
> Those are the
>kind of bits are what are normally mingled into the
hash.
I reckon that, given a suitably endian-correted input,
I could make an adequate hash by using a switch based on
the 5 bit major opcode to decide which bits from the first
16
bit word to use.
Most frequent instructions should get distinct hash values
that way.
The two main remaining weak points are 32 bit opcode shifts,
which will
hash all into the same bucket as atomic exchange, trap and
sleep
(the bits to distinguish these are actually in the 2nd 16
bit word),
and 16 bit subroutine returns, which hash with some less
frequent patterns
into a bucket of 11.
> Maybe your
>base_insn designation is too small.
Having read the description of base_insn in
cgen/doc/rtl.texi, I don't see
how anything but 16 bit can be correct for ARCompact.
>Indeed, but if you can accept a lesser standard of
proof, you could
>leave this part of the port till the end.
Yes. To test anything, I have to make it build first 
I had already written the hash function, only to discover
that the
endian check depended on an argument that was not passed to
my
macro/function.
Its easy to change his code into incorrect and/or useless
(return 0) code that
will compile, but there is still a lot of other stuff to fix
before I have something
that I can test.
I was hoping to get there without leaving FIXMEs left and
right... alas, if the infrastructure
allows no sane way to compute a hash on bi-endian processors
with variable instruction size,
it seems I have to punt on this issue for now.
Unless otherwise expressly stated, this message does not
create or vary any contractual relationship between you and
ARC International. The contents of this e-mail may be
confidential and if you have received it in error, please
delete it from your system, destroy any hard copies and
telephone the above number. Incoming emails to ARC may be
subject to monitoring other than by the addressee. EL
|