From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28036 invoked by alias); 12 Apr 2005 18:07:04 -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 27582 invoked from network); 12 Apr 2005 18:06:54 -0000 Received: from unknown (HELO pollux.ds.pg.gda.pl) (153.19.208.7) by sourceware.org with SMTP; 12 Apr 2005 18:06:54 -0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id EB554E1C82; Tue, 12 Apr 2005 20:06:48 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24368-07; Tue, 12 Apr 2005 20:06:48 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A6F82E1C80; Tue, 12 Apr 2005 20:06:48 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j3CI6p2A025305; Tue, 12 Apr 2005 20:06:52 +0200 Date: Tue, 12 Apr 2005 18:07:00 -0000 From: "Maciej W. Rozycki" To: Eric Christopher Cc: Daniel Jacobowitz , Atsushi Nemoto , binutils@sources.redhat.com Subject: Re: "Error: constant too large" on mips gas In-Reply-To: <1113255609.5094.18.camel@localhost.localdomain> Message-ID: References: <20050401.123528.122254594.nemoto@toshiba-tops.co.jp> <20050404.175833.115610647.nemoto@toshiba-tops.co.jp> <1112638226.5320.0.camel@localhost.localdomain> <20050409153120.GA7020@nevyn.them.org> <1113068818.5494.4.camel@localhost.localdomain> <1113255609.5094.18.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-SW-Source: 2005-04/txt/msg00290.txt.bz2 On Mon, 11 Apr 2005, Eric Christopher wrote: > This is all OK for 2.16, committing it to mainline for the current > timeframe is ok since you plan on working on a different implementation. > I'd like them to be mostly the same while working on things. > > Interestingly enough there's still the problem of this: > > la $2,0x80000000 > > on 64-bit abis. I believe the general consensus is to sign-extend the > constant when loading it. Currently we expand to: > > ori $2,$0,0x8000 > dsll $2,$2,0x10 > > which ends up getting us a zero-extended value which ends up being > unpredictable for calculations based on that. Well, with "-mabi=32" or "-mabi=n32" I get: lui $2,0x8000 and with "-mabi=64" I get: ori $2,$0,0x8000 dsll $2,$2,0x10 (and a warning about "la" being used with a 64-bit address). I do believe this is exactly what is desired. I'm afraid for "-mabi=64" you are expected to specify "0xffffffff80000000" explicitly -- there are no excuses. > > I haven't updated documentation though, as I consider it a short-term > > hack for 2.16 only. For 2.17, I think expr() should be modified to be > > able to do signed arithmetic/logic and perform operations modulo (1 << n), > > at least for reasonable values of n. Therefore only that implementation > > would be able to specify the desired number ranges accepted rather than > > accept what happens to be implemented. > > > > Does it sound reasonable? I hope so. > > Elaborate a bit please? It sounds ok so far, but I like examples :) Well, no code example as I haven't touched it yet, but semantically-wise I think calls to expr() should should be able to specify the width of the ALU word to operate on and whether to treat literals as signed or not. Then any literal will get internally either zero- or sign-extended from the specified width to the width of the internal representation (i.e that of offsetT) as will any results produced. Encountering a literal wider than the specified width should probably result in treating it as O_big. This way we'll be able to specify precisely when we want to know about falling outside the 32-bit space (and possibly the 16-bit one, too) as well as get information about it having actually happened. And we'll avoid the ambiguity of whether bits 63:32 are all set as a result of a logical negation of a legitimate 32-bit number or were actually incorrectly coded in a source. > I'm working on some documentation for all of the macro instructions we > support since this is getting to be mind numbing as to what we should > expect and how we handle it. Any start that you have would be nice as > well. I have no written document available of any kind, but I can surely provide feedback. Maciej