From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25929 invoked by alias); 31 Jan 2005 22:22:35 -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 25465 invoked from network); 31 Jan 2005 22:22:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 31 Jan 2005 22:22:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.43 #1 (Debian)) id 1Cvjvi-0003Kg-OM; Mon, 31 Jan 2005 17:21:58 -0500 Date: Mon, 31 Jan 2005 22:22:00 -0000 From: Daniel Jacobowitz To: Richard Sandiford Cc: binutils@sources.redhat.com Subject: Re: Bignums and .sleb128 Message-ID: <20050131222158.GA12709@nevyn.them.org> Mail-Followup-To: Richard Sandiford , binutils@sources.redhat.com References: <20050131195417.GA6254@nevyn.them.org> <87brb5p9mp.fsf@firetop.home> <20050131215739.GA11513@nevyn.them.org> <87sm4hqm3v.fsf@firetop.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sm4hqm3v.fsf@firetop.home> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2005-01/txt/msg00575.txt.bz2 On Mon, Jan 31, 2005 at 10:17:56PM +0000, Richard Sandiford wrote: > 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 ;) I suppose that's one way to look at it. If you assume that this code's assumptions are correct, then it follows that this code is correct; the bug is earlier. There's still a bug, we've just rocked the terrarium a bit :-) > > > 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? Lots of places in the backend check that the bignum has a certain size. These tests will break down with an additional sign-extension word. Something's gotta give. -- Daniel Jacobowitz