mipsisa32-unknown-elf-as: Error: too large constant specified

[Thiemo Seufer]

Nigel Stephens wrote:
[snip]
> I'm happy with it. But note that this doesn't return the behaviour to 
> what cgd was seeing on the old assembler when compiling for a 64-bit 
> ISA. It will now compile
> 
>        or      $2, $2, 0xe0000000
>        and     $2, $2, ~0xe0000000
> 
> to the same sequence for both a 32 and 64-bit arch:
> 
>   0:   3c01e000        lui     at,0xe000
>   4:   00411025        or      v0,v0,at
>   8:   3c011fff        lui     at,0x1fff
>   c:   3421ffff        ori     at,at,0xffff
>  10:   00411024        and     v0,v0,at
> 
> But I'd claim that's correct: it's not sensible for the assembler to 
> interpret immediate operands differently depending on the architecture.

It would be obviously broken for an 64 bit architecture. Fortunately,
it produces for 64 bit archs:

       0:       3401e000        li      at,0xe000
       4:       00010c38        dsll    at,at,0x10
       8:       00411025        or      v0,v0,at
       c:       2401ffff        li      at,-1
      10:       00010c38        dsll    at,at,0x10
      14:       34211fff        ori     at,at,0x1fff
      18:       00010c38        dsll    at,at,0x10
      1c:       3421ffff        ori     at,at,0xffff
      20:       00411024        and     v0,v0,at

> It 
> should only interpret immediates as truly 64-bit if they are used with 
> explicit 64-bit instructions (e.g. daddu, dli, etc), which is what this 
> patch will do.

Note that 'and', 'or' etc. instructions work on 64 bit values, too.

> Ian wrote:
> 
> >With the patch I sent out, code like this will assemble without a
> >warning on a 32-bit target:
> >	and	$2, $2, 0xffffffffe0000000
> >which is somewhat dubious.
> >
> 
> 
> Oh I don't know - that's a valid 32-bit immediate with 64-bit sign 
> extension. The more ugly thing is that it would allow:
> 
> 	and	$2,$2,0xffffffff1f000000 
> 
> But I'm prepared to look the other way if you are. :-)

Another example is

	ld	$2, 0xffffffff1fffffff

, where it silently discards the upper 32 bits. This is the reason
why I disallowed it. It never occured to me the complement operator
would produce such a result. :-)

IMHO the right solution is to fix these 32 bit values after each
call of my_getExpression().


Thiemo