This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] modify crt0.S for 64-bit address targets


>>>>> "Eric" == Eric Christopher <echristo@redhat.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]