From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3480 invoked by alias); 1 Feb 2005 00:53:14 -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 3192 invoked from network); 1 Feb 2005 00:53:03 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org with SMTP; 1 Feb 2005 00:53:03 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc11) with SMTP id <2005020100530101300lblcce>; Tue, 1 Feb 2005 00:53:02 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 01 Feb 2005 00:53:00 -0000 Subject: Re: Bignums and .sleb128 From: Paul Schlie To: Daniel Jacobowitz , Richard Sandiford CC: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-02/txt/msg00003.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. Strongly suspect that the proper idiom to is to treat all non-explicitly negative constants as being unsigned values; where the point of confusion is that with the exception of decimal numbers; binary, octal, and hex digits directly correspond to N-bit patters which were likely specified as such with the implicit intent they be preserved, the only remaining ambiguity is whether the most-significant specified set-bit is intended to be sign-extended if the value is stored with greater precision than than the otherwise required as determined by the most-significant non-0 bit position i.e.: -0x1 == [1...]1, where [1...] represents the variable precision sign-extension of the most significant bit explicitly specified, which would otherwise only require a signed-bit-field:1, but would need to be sign extended to fill the remaining most-significant bits if stored with greater precision as may be required. Thereby all constant values may be treated uniformly: +1 == +0b01 == +0x1 ... -1 == -0b01 == -0x1 ... +2 == +0b10 == +0x2 ... -2 == -0b10 == -0x2 ... Which seems quite sensible.