From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16206 invoked by alias); 6 Apr 2005 19:31:37 -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 16137 invoked from network); 6 Apr 2005 19:31:25 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 6 Apr 2005 19:31:25 -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 j36JVOja022459; Wed, 6 Apr 2005 15:31:25 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j36JVOIT022454; Wed, 6 Apr 2005 15:31:24 -0400 Received: from pkoning.equallogic.com ([172.16.1.106]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Apr 2005 15:31:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16980.14602.380063.574194@gargle.gargle.HOWL> Date: Wed, 06 Apr 2005 19:31:00 -0000 From: Paul Koning To: echristo@redhat.com Cc: cgd@broadcom.com, newlib@sources.redhat.com, binutils@sources.redhat.com Subject: Re: [patch] modify crt0.S for 64-bit address targets References: <1112768205.5493.2.camel@localhost.localdomain> <1112812609.5554.2.camel@localhost.localdomain> X-OriginalArrivalTime: 06 Apr 2005 19:31:23.0847 (UTC) FILETIME=[37D0B570:01C53ADF] X-SW-Source: 2005-04/txt/msg00173.txt.bz2 >>>>> "Eric" == Eric Christopher writes: Eric> On Tue, 2005-04-05 at 23:46 -0700, cgd@broadcom.com wrote: >> (added cc: to binutils list.) >> >> Eric, >> >> My take on this is that the problem is **not** that addu/subu are >> incorrect, but rather that the address being loaded is not what's >> intended! >> >> The intended address (K0BASE) is 0xffffffff80000000, and based on >> your comments (and the detection of the UNPREDICTABLE condition), >> I believe that 0x0000000080000000 is being loaded instead. >> Eric> Assuredly this is the case. I think the problem might be from Eric> using the ori instead of addi for the address. ori zero extends Eric> the constant, addi sign extends. IIRC all addresses should be Eric> sign extended and as such we should be using addi here yes? I Eric> seem to recall that we changed this a while back because the Eric> ori was some small amount faster. Faster? On a RISC machine? Seems odd. Anyway, ori is fine. The sequence for LA is LUI then ORI, and LUI loads a sign-extended 32 bit value with zeroes in the low order. So ORI is the easy way to fill in the low order. The LUI is what ensures that the value is formatted correctly in 64 bit registers. ADDI or ADDIU both sign-extend the 16-bit argument, so doing an LA with one of those, while possible, is more trouble because the LUI argument has to be adjusted up by 1 if the low half of the value to load is > 7fff. With ORI, the argument is zero-extended so it the low bits aren't a consideration when picking the LUI argument paul