From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16758 invoked by alias); 2 Mar 2005 16:42:52 -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 16529 invoked from network); 2 Mar 2005 16:42:39 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 2 Mar 2005 16:42:39 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j22Ggcja017926 for ; Wed, 2 Mar 2005 11:42:39 -0500 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j22GgcIT017921; Wed, 2 Mar 2005 11:42:38 -0500 Received: from pkoning.equallogic.com ([172.16.1.139]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Mar 2005 11:42:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16933.60668.593633.808034@gargle.gargle.HOWL> Date: Wed, 02 Mar 2005 16:42:00 -0000 From: Paul Koning To: ica2_ts@csv.ica.uni-stuttgart.de Cc: rsandifo@redhat.com, binutils@sources.redhat.com Subject: Re: Address sizes on 64-bit MIPS targets References: <87vf8byvqm.fsf@firetop.home> <20050302025754.GC1272@rembrandt.csv.ica.uni-stuttgart.de> <87psyitmny.fsf@firetop.home> <20050302145934.GE1272@rembrandt.csv.ica.uni-stuttgart.de> X-OriginalArrivalTime: 02 Mar 2005 16:42:38.0050 (UTC) FILETIME=[D7E97420:01C51F46] X-SW-Source: 2005-03/txt/msg00078.txt.bz2 >>>>> "Thiemo" == Thiemo Seufer writes: >> ... >> It depends. You only get wrap-around when running in user mode. >> n32 code running in kernel or supervisor mode will not wrap >> around, so the results are sensitive to processor mode. >> >> And I'm not sure how predicatable the behaviour is for all 64-bit >> processors. The MIPS64 spec guarantees wrap-around for user mode >> programs when UX=0, but (for example) the description of >> supervisor and kernel addressing in the VR4100 manual says: >> >> Usually, it is impossible for 32-bit mode programs to generate >> invalid addresses. In an operation of base register + offset for >> addressing, however, a two's complement overflow may occur, >> causing an invalid address. Note that the result becomes >> undefined. >> >> But maybe I'm being overly influenced by that ;) Thiemo> We have (potentially) two cases where all of this is used. A Thiemo> (currently not existing) n32 userland non-PIC mode, and n32 Thiemo> non-PIC kernel mode. In both cases, addresses which could Thiemo> wrap-around are invalid. There's just not point in handling Thiemo> them better than we already do. I'm a bit confused about which cases are being talked about here. Much of the discussion is about N32, and I'd agree that addresses bigger than 32 bits by definition have no meaning there. On the other hand, at some points N64 was mentioned. N64 has a flat, non-segmented, address space. Anything other than 64 bit arithmetic in the macro expansions would seem to be wrong if you're assembling for N64. So for example: >> Richard Sandiford wrote: >> However, if the sequence is: >> >> dla $2,0xa8000000000000 >> lw $2,0x100000($2) >> >> then the lw will use 32-bit address arithmetic: >> >> lui $1,0x10 >> addu $1,$1,$2 >> lw $2,0($1) >> >> and the behaviour will be unpredictable. that addu should be a daddu in N64. paul