From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5887 invoked by alias); 2 Oct 2009 17:58:50 -0000 Received: (qmail 5877 invoked by uid 22791); 2 Oct 2009 17:58:50 -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; Fri, 02 Oct 2009 17:58:46 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 2C2B56E3CE; Fri, 2 Oct 2009 10:58:45 -0700 (PDT) Message-ID: <4AC63F54.6040401@sebabeach.org> Date: Fri, 02 Oct 2009 17:58: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> <4AC4D17D.30308@sebabeach.org> <4AC4DA04.7080503@joguin.com> In-Reply-To: <4AC4DA04.7080503@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/msg00004.txt.bz2 Jean-Marc Saffroy wrote: > Doug Evans wrote: >> 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). > > You guessed right: my target arch has 32 bit instructions (which I > expressed with base-insn-bitsize == 32), and uses 64-bit words for > data and addresses (expressed with word-bitsize == 64). > >> 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. > > Good to hear, thanks! > > I found the cast could be fixed by changing the "(dfm 'DI..." line in > mode.scm, but have no idea about the possible side effects, and didn't > find a cure for the use of long anyway. > > > Cheers, > JM Ok, I understand what's going on. There's two separate issues. Using a long to store a 64-bit value is a long outstanding "todo" item to fix in the opcodes support. Working on a fix but I'm busy over the weekend so it'll be next week before the fix is checked in. The cast bug is related to the above "todo" item in that the fix will touch the same areas (the rtl->c generator for shifts doesn't properly handle 64-bit values). Blech, I wish I didn't have to use bfd for bfd_vma, bfd_uint64_t -like things, or reinvent all the work bfd has to put into those types.