This is the mail archive of the
mailing list for the binutils project.
was this change to MIPS assembly intentional?
- From: cgd at broadcom dot com
- To: binutils at sources dot redhat dot com
- Date: 06 Feb 2002 16:27:33 -0800
- Subject: was this change to MIPS assembly intentional?
So, between 2001-10-10 sources and sources as of a few days ago, I
noticed that the assembly of certain MIPS assembly code has changed.
In particular, when assembly for machines with 64-bit registers
(e.g. using -mips3, etc.), code like:
or $4, $4, 0xa0000000
used to assemble into:
0: 3c01a000 lui at,0xa000
4: 00812025 or a0,a0,at
and now it assembles into:
0: 3401a000 li at,0xa000
4: 00010c38 dsll at,at,0x10
8: 00812025 or a0,a0,at
I believe this to be intentional and correct. (The SGI assembler
generates the former for -o32, and the latter for -n32 and -64. See
Mips Run -- the only reference that i have that describes MIPS
assembler pseudo-ops/macros -- seems clear that the immediate arg to
an 'or' macro is unsigned, but doesn't clearly apply it to
32-vs-64-bit extension issues.)
But I wanted to be sure that it was intentional. 8-)
I think that stuff like this really merits additional notice in the
documentation and/or release notes... I noticed this because i ran
into (broken 8-) code which relied on the old behaviour. Who knows
how much additional code there is out there in the world which is
Maybe for 2.12, for MIPS, the release notes should say something like:
The MIPS assembler has significantly changed since the
previous release, and some code is assembled differently than
it has been with previous releases. Take care when upgrading
MIPS binutils to 2.12 if you are using hand-coded assembly.