Re: mipsisa32-unknown-elf-as: Error: too large constantspecified

[cgd at broadcom dot com]

At Tue, 14 Oct 2003 23:12:40 +0000 (UTC), "Ian Lance Taylor" wrote:
> Whether this is a bug or not is difficult to say.  What is the
> precision of the ~ operator?  What's happening is that ~0xe0000000 is
> being turned into 0xffffffff1fffffff.  That constant is indeed too
> large.  Naturally you want ~0xe0000000 to be 0x1fffffff.  But,
> currently, for any MIPS target, the assembler will do 64-bit
> arithmetic.

(err, when using a 64-bit BFD, right?  I think it still forces 32-bit
math, for better or worse, if using a 32-bit BFD... or maybe that
doesn't compile anymore.)


> Maybe for a 32 bit MIPS target the assembler should know
> to use 32-bit arithmetic.  Unfortunately that would not be a trivial
> change.

(Note that in all of the examples below, the problem regarding
interpretation of constants with bit 31 set has been fixed, i.e.,
they're no longer treated as signed, as they were until that was fixed
... a while ago, i forget exactly when.)

As of 2.13.2.1, assembling the code:

        or      $2, $2, 0xe0000000
        and     $2, $2, ~0xe0000000

with a 64-bit assembler, with -mips4 produces:

   0:   3401e000        li      at,0xe000       <- really ori
   4:   00010c38        dsll    at,at,0x10
                so at = 0x00000000e0000000
   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
                at = 0xffffffff1ffffffff
  20:   00411024        and     v0,v0,at

i.e., what you'd expect for a 64-bit arch, assuming that you treat
logical op operands as unsigned 64-bit numbers.

same assembler, with -mips2 produces:

   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

I.e., exactly what you'd expect for a 32-bit arch.


So, it used to work exactly as you describe for 64-bit code, Ian, but
also worked properly for 32-bit code.



I'd guess this is a recent regression.

I just checked a later, similar assembler, with version
"GNU assembler version 2.14.90 (sb1-elf) using BFD version 2.14.90 20030821"

and it produced the exact same assembled code.



cgd