I've now heard a bit of the history from Nigel at Algorithmics, and to
summarize, they chose the 6 and 7 values for MIPS32/64 after Cygnus, who were
also producing a MIPS32/64 toolchain, had chosen these. (Algor had originally
used the value of 5 for MIPS32, but had to changed when both SGI (who assigned
it to something else) and Cygnus chose otherwise). Hence ARCH_ALGOR_32.
A little research also reveals that the value of 5 for ARCH_32 was first
checked into CVS in Dec 2000 by Nick Clifton at Redhat.
Anyway, that's why things are the way they are, but may not help much as to a
My personal take on this is that the two main commercial providers (Cygnus and
Algor) of MIPS32/64-capable GNU toolchains have been using 6 & 7 for quite a
while, SGI "agree", and that this is quite a precedent. Hopefully the ABI
process will soon shake any other issues out too.
On Mon, 29 Jul 2002, Carsten Langgaard wrote:
> First of all I will like to thank you for all the replies, we really
> it, because it helps us in our process of making a proper ABI spec.
> I known it's a relative late state we are trying to provide the community
> with an
> ABI document, but I guess it's better to be late than to never show up.
> I believe we all could benefit from such a document, it's only in a internal
> version right now, but it might be a good idea to send it out to the
> community for
> comments, before the finally version.
> But we are still in an early state and on the learning curve.
> Regarding the ELF header arch values, we did try to select whose in order not
> break things for anyone.
> I'm also a little surprised to see these value out in binutils, it really
> me, if we got a linux toolchain that can generate mips32/mips64 code.
> MIPS32R2 and MIPS64R2 is a new enhanced version of MIPS32 and MIPS64
> which among other things include some new instructions.
> Regarding Algorithmics, I don't know if everybody are aware of it, but we have
> just acquired Algorithmics.
> That among other things, is done in order to play a stronger part in the
> development of the toolchain. And their work will be pushed back to the
> Algorithmics have done a MIPS32 compiler for us, which is very close to be
> I hope this clarify a little bit, what our motivation are.
> firstname.lastname@example.org wrote:
> > At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
> > > I'd like to fix binutils ASAP. Here is a patch.
> > OK, so, I've seen no response so far that indicates that binutils
> > should actually be changed.
> > to recap:
> > * Binutils has deployed these values in several releases now, and I
> > know for a fact that people are using binaries with these values.
> > * SGI has followed binutils' lead in selecting values.
> > * Algorithmics did something else, though it's not clear what the
> > difference between "ARCH_ALGOR_32" and "ARCH_32" really is.
> > It seems obvious that the simplest solution that causes the least pain
> > all around is to go with the numbering binutils currently uses. This
> > will probably cause a little bit of pain for Algorithmics, but, well,
> > they could have sent something to binutils to indicate use of that
> > number, and i'm quite sure that most of the rest of us have had to put
> > temporary backward-compat hacks in our own codebases for incompatible
> > changes made by others in the past. It's not that hard and doesn't
> > cause long-term pain.
> > I could understand that MIPS or Algorithmics might like that, but I
> > think there're a bunch of morals to this story: if you want to lead on
> > ABI issues, get out in front of them (you can't lead from the back
> > 8-); interact with the tool development and use communities about such
> > issues _before_ solutions are needed and agreed upon in those
> > communities; and, you're hacking open source code like binutils,
> > contribute your changes back as soon as you possibly can.
> > I'd also like to point out that saying "mips will be defining this
> > ABI, so you should all change your code to work with it" without,
> > AFAIK, even providing a draft of said ABI... is unlikely to produce
> > positive results even _if_ there's no precedent that would go against
> > the requested change. (if somebody has a ptr, i'd be glad to be
> > corrected 8-)
> > (I wonder what other incompatibilities may exist between this new ABI
> > and the current binutils MIPS ELF headers...)
> > cgd
> > --
> > Chris Demetriou Broadcom
> > Corporation
> > Senior Staff Design Engineer Broadband Processor Business
> > Unit
> > Any opinions expressed in this message are mine, not necessarily
> > Broadcom's.
> _ _ ____ ___ Carsten Langgaard Mailto:email@example.com
> |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
> | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
> TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
> Denmark http://www.mips.com
Dan Temple, Eng. Mgr. Tel: +45-44865512
MIPS Denmark Fax: +45-44865556
Lautrupvang 4B mailto:firstname.lastname@example.org
DK-2750 Ballerup http://www.mips.com