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

[cgd at broadcom dot com]

At Wed, 15 Oct 2003 15:48:28 +0100, Nigel Stephens wrote:
> Indeed. My argument is that it is "surprising" for the assembler to
> ever generate zero-extended 64-bit immediate values for any
> instruction that is not explicitly 64-bit. I agree that the logical
> operations, which don't have 64-bit variants, are a problem - but
> surely portability of existing 32-bit code is crucial. If I'm
> recompiling a 32-bit C program for the n32 ABI, then I don't expect to
> have to change anything - unless I explicitly use long long.

ironically, as noted earlier, it seems that compatibility with the
irix tools one of the justifications for the change:

with them, as noted earlier, the behaviour of values with bit 31 set
match the current binutils behaviour.


> With the current behaviour, ostensibly correct code working with
> 32-bit values will now generate invalid results if compiled for a
> 64-bit ISA,  even if the code never uses 64-bit operands. If I was
> porting this piece of 32-bit assembler code to say the n32 or o64 ABI,
> then it would generate an *unpredictable* result:
> 
> 	li	$2, 0x1234
> 	or	$2, $2, 0x80000000
> 	addu	$2, $2, 1

well, one would hope this would be something like: "or $2, $2,
KSEG0_BASE" or something.  (That's what it was like in some of our
source, and yes, we had to ... change the #define.)

One "programming guideline" would be to make sure that when switching
from logical ops to 32-bit arithmetic ops, to sll first if one wants
portable code.

One could easily do this in a way that doesn't hurt 32-bit code, and
it puts the onus on people who want to run safely on 64-bit machines.
(There are already a lot of changes people really should deal with,
it's just one more.)  And it doesn't hurt people who don't intermix
arithmetic and logical ops on the same values, at all.


> That's unambiguous, and puts the onus on the author of the 64-bit
> assembler source code.

At the expense of a serious amount of code clarity, IMO.

FWIW, another possible conclusion from your argument is that, really,
the logical psedo-ops are inherently ambiguous, and maybe should be
removed entirely.  8-)

Having a logical op's immediate operand get sign extended magically
iff bit 31 is set (or maybe if bits 63:32 are all 0) violates some
notion that the assembler will treat input values consistently, and
that if one can generate 0x800000000 one can equally generate
0x80000000.

Especially if one uses lots of #defined constants (and who doesn't
these days? 8-), then why should:

        #define FOO (1<<30)
        #define FOO (1<<31)

be expected to behave vastly differently on a 64-bit arch?


Some more thoughts:

(1) if the decision to go 'back' to the sign-extended 32-bit values
was made, IMO *all* 64-bit values should be rejected.

(2) I suspect that either way, a significant change would cause people
-- who probably just had to tweak their code slightly -- to have to
change their code in even more significant ways.  (i.e., they just had
to add 0xffffffff to the start of their constants, with a change like
you propose recoding would be required, alas.)

(3) "The whole SGI thing."  Really, yeah, the problem is too many
ill-documented pseudo ops.  8-)



chris