This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Ian Lance Taylor wrote:

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?


My eyeballs! My built-in compiler is obviously a bit buggy. Apologies for any confusion.


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?



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.


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


[If the 'or' immediate operand is zero extended by the assembler to 0x0000000080000000, then we've now generated an invalid operand for "addu", since 32-bit MIPS arithmetical operations are only defined to generate valid results if their inputs are correctly sign-extended, in other cases their result is "unpredictable".]


I'd have to rewrite the code like this to get the original 32-bit semantics:

	li	$2, 0x1234
	or	$2, $2, 0xffffffff80000000
	addu	$2, $2, 1

Now that seems perverse! It would be easy enough for an assembler programmer writing 64-bit code from scratch, and wanting a zero-extended operand for 'or', 'and', etc, to write their new code thusly:

	dli	$3, 0x80000000
	or	$2, $2, $3


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


The problem is of course the assembler language definition, or rather the lack of it - both See MIPS Run and the old SGI assembler manual are ambiguous on this point. Sadly I can see that I'm going to lose this argument, because SGI got there first with their assembler and did it the "wrong" ;-) way.

Nigel



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]