From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15381 invoked by alias); 3 Jan 2012 10:57:38 -0000 Received: (qmail 15373 invoked by uid 22791); 3 Jan 2012 10:57:36 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mms3.broadcom.com (HELO MMS3.broadcom.com) (216.31.210.19) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Jan 2012 10:57:23 +0000 Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 03 Jan 2012 03:04:59 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB02.corp.ad.broadcom.com (10.9.200.133) with Microsoft SMTP Server id 8.2.247.2; Tue, 3 Jan 2012 02:56:38 -0800 Received: from [10.177.72.88] (unknown [10.177.72.88]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id A0408BC395 for ; Tue, 3 Jan 2012 02:57:08 -0800 (PST) Message-ID: <4F02DF03.1030701@broadcom.com> Date: Tue, 03 Jan 2012 10:57:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cgen@sourceware.org Subject: Re: Encoding of immediates different to label addresses References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2012-q1/txt/msg00002.txt.bz2 On 02/01/2012 09:44, Julius Baxter wrote: > I'm working on fixing up the OpenRISC 1000 CGEN port and have come > across something I find I can't quite do with CGEN. > > For the jump and branch instructions, if we use immediate value number > specified in the assembly, we need that encoded into the instruction > without any shifting occurring to it. > > Eg. "l.bf 1" should become 0x10000001, "l.bf 4" should become 0x10000004 etc. > > These target addresses are shifted-left by two during decoding, and so > "l.bf 1" is actually a branch of 4 bytes. > > If we use a label for an address, though, I'm seeing that we're > getting the offset in bytes during encoding, which then needs to be > shifted right by two before being put in the instruction. > > But it seems we can have the shifting on both numerical immediates and > labels, or neither. (Pardon my incorrect use of terminology, I have a > feeling I'm not quite calling everything its right name!) > > Upon inspecttion, it looks like the binutils port we have been using > for the past few years (not CGEN-based) has a right-shift of 2 in the > md_apply_fix() function in binutils/gas/config/tc-or32.c ( > http://sourceware.org/git/?p=binutils.git;a=blob;f=gas/config/tc-or32.c;h=7234fb837e006f979c255f62206e39a9822046d2;hb=HEAD#l603 > ) when the instruction had the actual value of the label inserted into > it. > > Is there any way to handle this using the CGEN description? I don't know about that. > The current instruction field definition being used is: > > (df f-disp26 "disp26" (PCREL-ADDR) 25 26 INT > ((value pc) (sra WI (sub WI value pc) (const 2))) > ((value pc) (add WI (sll WI value (const 2)) pc))) > > This does the shifting on encode and the target label addresses are > right but the numerical immediates are wrong, but if I remove the sra > on the encode, the numerical immediates are right but the target label > addresses are wrong. > > I've had a bit of a poke around and seen the function > gas_cgen_md_apply_fix() is used as a generic md_apply_fix() function, > but can't quite see where I might be able to hook in things for > particular encoding cases. What might work is to drop the shifting from the field definition and create your own md_apply_fix function something like this, void md_apply_fix (fixS *fixP, valueT *valP, segT seg) { if (fixP->fx_done && fixP->fx_r_type == BFD_RELOC_UNUSED + OPERAND_ID_OF_BRANCH) { gas_assert (fixP->fx_addsy == NULL); gas_assert (fixP->fx_subsy == NULL); *valP >>= 2; } gas_cgen_md_apply_fix (fixP, valP, seg); } Good luck! Andrew