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

[Eric Christopher <echristo@redhat.com>]

> 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.
> 

I think "the sequence" is probably a bit much. Right now we're not doing
LUI, and merely going with load register because the code sequence looks
like this:

la t1,K0BASE

which has K0BASE defined to 0x80000000, so all we're really doing is
putting a value into a register and then doing work off of that.

Really, I suppose we should just be putting the immediate in the
register, instead of treating it as an address, e.g.

li t1,K0BASE

which does cause the unpredictability problems to go away.

The code that's loading the value is load_register and it's the last set
of code in the function if you want to look.

> 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

Fair enough, it was just a thought. I hate macros and so figuring out
what we really mean when "blah" is annoying.

-eric