From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5827 invoked by alias); 26 Jan 2007 01:11:12 -0000 Received: (qmail 5819 invoked by uid 22791); 26 Jan 2007 01:11:11 -0000 X-Spam-Check-By: sourceware.org Received: from mailgate-el01.arc.com (HELO elexch01.arc.com) (194.202.198.236) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Jan 2007 01:11:07 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CGEN_DIS_HASH: how to get endianness and/or instruction size? Date: Fri, 26 Jan 2007 01:11:00 -0000 Message-ID: <20A30789B9F48C4E9D71A188EFE8042C2BC65C@elexch01.arc.com> From: "Joern Rennecke" To: "Frank Ch. Eigler" Cc: Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00028.txt.bz2 =20 From: Frank Ch. Eigler=20=20 >Hi - Hi. >Where are the bits that allow the insn to be decoded as a branch?=20 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.=20 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 t= hat 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.=20 Unless otherwise expressly stated, this message does not create or vary any= contractual relationship between you and ARC International. The contents o= f this e-mail may be confidential and if you have received it in error, ple= ase delete it from your system, destroy any hard copies and telephone the a= bove number. Incoming emails to ARC may be subject to monitoring other than= by the addressee. EL=20=20 =20 =20 =20