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

[Nigel Stephens]

cgd@broadcom.com wrote:

>>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.)
>

Yeah, and for KSEG0_BASE that can be explained away, given the shape of 
the MIPS 64-bit address map.

But it's not so clearly right if you're doing bit manipulation:

 #define DEV_STATE_MASK	0xc0000000
 #define DEV_STATE_SHIFT 30

	lw	$v0,DEV_REG
	and	$v0,DEV_STATE_MASK
	srl	$v0,DEV_STATE_SHIFT


OK, that's not the best way to code something like this, but you get my 
drift - it's not going to work when compiled -mips4, since srl's input 
is now an invalid 32-bit value if bit 31 was set. Having to define it 
like this is pretty non-obvious:

#define DEV_STATE_MASK	0xffffffffc0000000


>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.
>

Ick. (c) Eric Christopher.

>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.
>  
>

I'll assume your tongue is firmly in your cheek!  That would be a 
horrible  and unnecessary addition to the MIPS architecture - not being 
able freely to intermix logical and arithmetic ops.

One of the really cool things about the 64-bit MIPS architecture is that 
there *isn't* a 64-bit mode switch: most 32-bit code just works on a 
64-bit CPU, no change required (assuming a 32-bit compatible ABI, of 
course). The CPU does the right thing - it's just the assembler which 
has created this portability problem, which we're proposing increasingly 
complex ways of working around.


>>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-)
>

Umm... perhaps not. ;-)

>
>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.
>  
>

Yes, at least all 64-bit immediates used on non-'d' instructions. But 
then that would mean adding 'dor', 'dand', etc, which is seen as icky, 
and I think I agree.


>(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.)
>  
>

Hey - maybe there should be an assembler command-line option for dusty 
deck code: -msign-extend-imm32 and -mno-sign-extend-imm32 ;-)

Nigel