Home Original page

was this change to MIPS assembly intentional?

cgd@broadcom.com cgd@broadcom.com
Wed Feb 6 16:49:00 GMT 2002 
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
similarly broken...

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.


chris
More information about the Binutils mailing list