This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: mipsisa32-unknown-elf-as: Error: too large constantspecified
At Wed, 15 Oct 2003 20:15:45 +0100, Nigel Stephens wrote:
> [ srl example ]
Yeah, that is an example that would break. Of course, it would also
produce remarkably inefficient code compared to a better example.
(BTW, in case it's not obvious, i actually do strongly care about
avoiding UNPREDICTABLE. If I didn't, I wouldn't have put support for
checking it in many cases into gdb's mips sim, and would have tortured
echristo and rsandifo about cases where GCC tripped those checks. 8-)
> >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.
Not really.
It's not like it's an architectural restriction, either: you just have
to think, carefully, about what you're doing. You can still shoot
yourself in <body part of choice>, but as a programming guideline for
people who don't no better, it seems like a reasonable one.
One should be thinking carefully when writing hand-coded assembly.
> 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.
Yes. Another, better, guideline for the initiate might be "don't use
pseudo-ops." (Kind of like "don't use goto.")
> Hey - maybe there should be an assembler command-line option for dusty
> deck code: -msign-extend-imm32 and -mno-sign-extend-imm32 ;-)
Heh, you could do that, or you could take the more popular approach
and pick totally random names for the assembler flags, not following
any particular convention well. 8-)
chris