From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21464 invoked by alias); 31 Jan 2005 22:18:13 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 21210 invoked from network); 31 Jan 2005 22:17:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 22:17:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0VMHvZS021030 for ; Mon, 31 Jan 2005 17:17:57 -0500 Received: from firetop.home (vpn50-89.rdu.redhat.com [172.16.50.89]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0VMHvO07984 for ; Mon, 31 Jan 2005 17:17:57 -0500 Received: from rsandifo by firetop.home with local (Exim 4.34) id 1Cvjro-0008Ch-DW for binutils@sources.redhat.com; Mon, 31 Jan 2005 22:17:56 +0000 To: binutils@sources.redhat.com Subject: Re: Bignums and .sleb128 References: <20050131195417.GA6254@nevyn.them.org> <87brb5p9mp.fsf@firetop.home> <20050131215739.GA11513@nevyn.them.org> From: Richard Sandiford Date: Mon, 31 Jan 2005 22:18:00 -0000 In-Reply-To: <20050131215739.GA11513@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 31 Jan 2005 16:57:39 -0500") Message-ID: <87sm4hqm3v.fsf@firetop.home> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00574.txt.bz2 Daniel Jacobowitz writes: >> You said later that: >> >> > If we're going to use these semantics, at least the '-' case in >> > operand() needs to be fixed. >> >> but I wasn't sure what you meant by "these semantics". Do you mean >> treating bignums as signed, or treating them as unsigned? By my reading, >> operand()'s current handling of '-' already assumes they are signed, >> just like the sleb128 code does (and did ;). > > It doesn't work, because sometimes bignums are signed and sometimes > they aren't. Consider -0xffffffffffff; the current code will return 1. > If you want to treat the input as unsigned, then you need to add a new > word with the sign bit. Note that with one less leading 'f', it > suddenly works. Right, that's exactly the point I made later. Like you say, if you treat the bignum as signed (as the current '-' code does), then {0xffff, 0xffff, 0xffff} is an invalid representation of a positive number, it should be {0xffff, 0xffff, 0xffff, 0x0000} instead. So the '-' code _does_ seem OK if you treat bignums as signed, the problem is that the integer parsing code is still assuming that bignums are unsigned, and that the extra 0x0000 littlenum isn't needed. I couldn't tell whether that's what you were saying too, or whether you think that opcode() is wrong even if bignums are treated as signed. It's quite possible we're in violent agreement here ;) > One approach to fix the problem would be to define X_unsigned as a > secondary "sign bit" for the bignum. The core changes for that would > be easy. It's the backends that bother me. I guess that's one way, but both existing bits of "bignums are signed" code just use the top bit of the bignum as the sign bit. Maybe that is the most natural representation? Richard