From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14462 invoked by alias); 1 Oct 2009 15:57:59 -0000 Received: (qmail 14441 invoked by uid 22791); 1 Oct 2009 15:57:57 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Oct 2009 15:57:52 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 9E2756E3CE; Thu, 1 Oct 2009 08:57:50 -0700 (PDT) Message-ID: <4AC4D17D.30308@sebabeach.org> Date: Thu, 01 Oct 2009 15:57:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jean-Marc Saffroy CC: cgen@sourceware.org Subject: Re: problem with 64-bit arch References: <4AC4BF97.8040302@joguin.com> In-Reply-To: <4AC4BF97.8040302@joguin.com> 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: 2009-q4/txt/msg00002.txt.bz2 Jean-Marc Saffroy wrote: > Hi, > > I am trying to use CGEN for an experimental 64-bit architecture (ie. > word-bitsize is 64), and in my case the generated arch-ibld.c file is > incorrect. > > I defined the following insn field: > > (df f-disp24 "disp24" (PCREL-ADDR) 8 24 INT > ((value pc) (sra WI (sub WI value pc) (const 2))) > ((value pc) (add WI (sll WI value (const 2)) pc)) > ) > > (define-operand > (name disp24) > (comment "24 bit signed displacement") > (type h-iaddr) > (mode WI) > (index f-disp24) > ) > > And arch-ibld.c contains the following code (in > _cgen_insert_operand): > > switch (opindex) > { > case _OPERAND_DISP24 : > { > long value = fields->f_disp24; > value = (() (((value) - (pc))) >> (2)); > errmsg = insert_normal (cd, value, > 0|(1< total_length, buffer); > } > break; > > Note the missing type in the cast before assigning to value. Also > using a long type for value will cause problems when running on a > 32-bit host, since it operates on 64-bit values. > > I had a quick look at the other two archs that use word-bitsize 64, > ie. sparc64 and ia64, and it seems they use multi-ifields for this > kind of PC-relative field, which may be an artificial way of avoiding > the problem. > > Is there an obvious fix to this problem? > Obvious? Possibly. For reference sake, there are several separate notions here: data word bitsize, and instruction word bitsize. sparc64 has 64/32, ia64 has 64/64 [IIUC, and I'm leaving out "bundles", I don't know ia64 that well] [For completeness sake, there's also data address and instruction address word bitsize. I'm guessing they're 64 here, same as data word bitsize, so we can ignore them.] We were just discussing instruction word bitsizes of 64, and it's not clear what to do. I don't mind going down the path of having 64 bit instructions expressed as a single 64 bit integer (*1), but can you confirm your architecture has 64-bit instructions? From the given sample, it seems like it has 32 bit instructions and 64-bit words (like sparc64). Clearly the missing type in the cast is a bug. That should be easy to fix. As for the use of long to record a 64-bit value, that should also be (relatively) easy to fix. I'll dig deeper tonight. (*1): It would foreclose using such ports on hosts that don't have 64-ints, but I don't mind, personally. [I wonder if someday we'll want to use SI/DI/etc. to represent instructions. That's *way* down the road, if ever.]