mipsisa32-unknown-elf-as: Error: too large constant specified
Maciej W. Rozycki
macro@ds2.pg.gda.pl
Wed Oct 15 15:45:00 GMT 2003
On Wed, 15 Oct 2003, 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.
Well, I suppose we can add "dand", "dor" and "dxor" support to gas
(following the "dli" precedent), but a sane C compiler should be aware it
is generating n32 code and sign-extend immediates as appropriate itself in
the first place. And you shouldn't expect hand-written assembly to be
portable across ABIs, IMO.
> 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.
It is, but one might want to write that as:
.set push
.set noat
dli $1, 0x80000000
or $2, $2, $1
.set pop
to avoid wasting a register and the resulting code starts becoming
obscure, sigh...
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
More information about the Binutils
mailing list