Re: MIPS HAVE_32BIT_ADDRESSES bogon ?

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

cgd@broadcom.com wrote:
[snip]
> > If the latter, it's better to check for -mlong64 for this
> > purpose, an option which doesn't exist in gas yet.
> 
> I actually think this is a bit insane.  The notion of having to
> explicitly tell the assembler that higher-level langauge 'pointers'
> and 'longs' (what's a long to the mips assembler?  that thing that
> .long generates as 4 bytes?  8-) seems ... wrong.

I'm not too happy with this idea, too. In principle, the compiler
should do the necessary expansions if it wants 64bit (with the
potential gain of better scheduling). Unfortunately, there is
currently no way to tell the assembler to do 64bit addressing
in a 32bit object format.

> What's the _harm_ in generating 'd' ops for embedded-pic if there are
> 64-bit GPRs?  (heck, what's wrong with using them for e.g. n32?!)
> 
> I guess I actually don't get, in general, the harm of using the 'd'
> ops when ptr size is 32 bits.  is this to make _sure_ you get
> overflow?  do e.g. SGI assemblers do this?

The SGI assembler seems to use consistently the lowest ISA
required for the job. I don't know what might or might not
break when overflow behaviour is changed.

> Actually, this led me to an "uh oh!": mips-opc.c is quite happy to
> unconditinoally implement e.g. 'la' as addiu...  that seems ... wrong,
> eh?

la uses addiu, dla uses daddiu. What's wrong with this?


Thiemo