This is the mail archive of the cgen@sourceware.org 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: CGEN_DIS_HASH: how to get endianness and/or instruction size?



 
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  
 
 
 


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