Re: "Error: constant too large" on mips gas

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Mon, 11 Apr 2005, Eric Christopher wrote:

> This is all OK for 2.16, committing it to mainline for the current
> timeframe is ok since you plan on working on a different implementation.
> I'd like them to be mostly the same while working on things.
> 
> Interestingly enough there's still the problem of this:
> 
> la $2,0x80000000
> 
> on 64-bit abis. I believe the general consensus is to sign-extend the
> constant when loading it. Currently we expand to:
> 
> ori $2,$0,0x8000
> dsll $2,$2,0x10
> 
> which ends up getting us a zero-extended value which ends up being
> unpredictable for calculations based on that.

 Well, with "-mabi=32" or "-mabi=n32" I get:

lui	$2,0x8000

and with "-mabi=64" I get:

ori	$2,$0,0x8000
dsll	$2,$2,0x10

(and a warning about "la" being used with a 64-bit address).  I do believe 
this is exactly what is desired.  I'm afraid for "-mabi=64" you are 
expected to specify "0xffffffff80000000" explicitly -- there are no 
excuses.

> >  I haven't updated documentation though, as I consider it a short-term 
> > hack for 2.16 only.  For 2.17, I think expr() should be modified to be 
> > able to do signed arithmetic/logic and perform operations modulo (1 << n), 
> > at least for reasonable values of n.  Therefore only that implementation 
> > would be able to specify the desired number ranges accepted rather than 
> > accept what happens to be implemented.
> > 
> >  Does it sound reasonable?  I hope so.
> 
> Elaborate a bit please? It sounds ok so far, but I like examples :)

 Well, no code example as I haven't touched it yet, but semantically-wise 
I think calls to expr() should should be able to specify the width of the 
ALU word to operate on and whether to treat literals as signed or not.  
Then any literal will get internally either zero- or sign-extended from 
the specified width to the width of the internal representation (i.e that 
of offsetT) as will any results produced.  Encountering a literal wider 
than the specified width should probably result in treating it as O_big.

 This way we'll be able to specify precisely when we want to know about 
falling outside the 32-bit space (and possibly the 16-bit one, too) as 
well as get information about it having actually happened.  And we'll 
avoid the ambiguity of whether bits 63:32 are all set as a result of a 
logical negation of a legitimate 32-bit number or were actually 
incorrectly coded in a source.

> I'm working on some documentation for all of the macro instructions we
> support since this is getting to be mind numbing as to what we should
> expect and how we handle it. Any start that you have would be nice as
> well.

 I have no written document available of any kind, but I can surely 
provide feedback.

  Maciej