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

[Ian Lance Taylor <ian at wasabisystems dot com>]

Nigel Stephens <nigel@mips.com> writes:

> 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

Hmmm, that's not what I see.  When I run with the -mips4 option, I get
this:
   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

Which is what cgd saw also.  I configured for mips-elf.  What did you
configure for?

> But I'd claim that's correct: it's not sensible for the assembler to
> interpret immediate operands differently depending on the
> architecture. 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.

That might be nice.  But it's not what my patch does.  That requires a
considerably more complex patch.

Moreover, it's difficult to interpret your suggestion for instructions
like `or' and `and'.  Those instructions don't have `d' variants; they
don't need them, because the operation is well defined whether working
with a 64-bit value or a sign extended 32-bit value.  In this case,
the assembler is synthesizing an immediate value for `or' and `and'.
What size should it synthesize for, when assembling for a 64-bit
target?

Ian