Re: accept 64-bit constant addresses in mips n32

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

Alexandre Oliva wrote:
> On Apr  8, 2003, Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de> wrote:
> 
> > After thinking a bit about this, I'm still not sure if the 'fix' is ok.
> > n32 normally guarantees properly sign-extended 32-bit addresses, and
> > people may rely on it for pointer arithmethics (in broken code).
> 
> I believe the point is that, if you really know what you're doing to
> the point of inserting a 64-bit address explicitly in your n32
> assembly code, there's no reason for the assembler to not do it other
> than just being picky.

The one who really knows what he is doing encloses it in a
.set mips3 / .set mips0 pair.

> > IMHO the assembler should complain about attempted 64-bit addressing
> > in order to catch compiler bugs.
> 
> > For what actual usage scenario was this patch developed?
> 
> It's a trick from mips64 linux (the kernel) folks: they build the
> kernel with -mabi=64, but assemble it as -n32 (-Wa,-n32),

Actually they are using o32 for this purpose currently.

> such that,
> for some reasons I haven't really investigated, the resulting kernel
> binary is far smaller and more efficient than assembling everything as
> n64, linking as n64, then converting to an ELF32 format (as required
> by a number of mips boot loaders) with objcopy.

This technique shrinks 64bit values to sign extended 32bit, at least
when you sprinkle some casts in the C code at strategic places. This
makes register loading much cheaper (2 vs. 6 insns), but the whole
thing is somewhat fragile.

IMHO the proper way is to add an --assume-sign-extended-addresses switch
to gas, and handle the macro expansions in load_assress and for DLA
accordingly. This will leave other load/stores working properly, without
specialcasing.

> That said, Chris came up with a follow-up patch, that addresses some
> of your concerns and fixes a merge bug I unintentionally introduced,
> but Eric still hasn't reviewed it.

I still don't like it. It loosens an ABI restriction by default, instead
of choosing the proper (n64) ABI and restrict it for better optimizations.


Thiemo