From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5644 invoked by alias); 1 Feb 2005 01:09: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 5548 invoked from network); 1 Feb 2005 01:09:20 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 1 Feb 2005 01:09:20 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <20050201010918014004m0ese>; Tue, 1 Feb 2005 01:09:19 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 01 Feb 2005 01:09:00 -0000 Subject: Re: Bignums and .sleb128 From: Paul Schlie To: Daniel Jacobowitz , Richard Sandiford CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-02/txt/msg00004.txt.bz2 So to be clearer: -1 == -0x1 == -0xF... So: assuming signed char:8, short:16, int:32, etc. -1 == (signed char)+0xFF == (short)+0xFFFF == (int)+0xFFFFFFFF -1 == (signed char)-0xFF == (short)-0xFFFF == (int)-0xFFFFFFFF and correspondingly: 1 == (unsigned char)+0x1 == (unsigned short)+0x1, etc. 255 == (unsigned char)-0x1, 65536 == (unsigned short)-0x1, etc. As: +0xF == [0...]1111 == 15 (as non-explicitly negative constant is unsigned) -0xF == [1...]1111 == -1 (as an explicitly negative constant is signed) > From: Paul Schlie >> 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. > >