Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
MIPS ABI History
ABI History
The MIPS ABI took shape as a set of register usage and calling conventions established from the earliest days of MIPS CPUs. It picked up the ABI acronym and a defined binding to object code with the AT&T-inspired UnixSystem V document which is rooted with SVR4.
That process had coalesced as early as 1990 into much of the o32 ABI which is widely used today. By about 1994 the ABI was expanded to encompass position-independent code and the ELF object code syntax, and there have been no substantive and intentional changes since.
SGI pioneered 64-bit operating systems for MIPS in the early 1990s, and the o32 ABI was quite unsuitable for real 64-bit computing. SGI defined a 64-bit ABI called n64 suitable for the largest applications; and then - belatedly realising that n64's 64-bit pointer and long types bloated programs and caused portability problems to many applications which didn't need them - produced the very similar standard n32, which differs primarily in having 32-bit pointers.
From 1995 or so SGI used solely 64-bit-capable MIPS CPUs, so they had no need to revisit a 32-bit ABI. As a result the embedded MIPS world is still stuck on the 20-year-old o32 standard. A series of talks five years ago failed to come up with a replacement.
Meanwhile, the perceived deficiencies of o32 have led to the proliferation of variants and more narrowly-focussed alternatives, to the point where there are now as many as 15 incompatible MIPS ABIs. It may yet prove the least worst decision for us all to continue to use o32 forever: but escaping from o32 could noticeably improve performance and ease various kinds of compatibility. So MIPS Technologies' has a proposal called NUBI to do this: but it won't make sense unless we can take the community with us and end up with fewer ABIs - not just another family to add to the overlong list.
Relevance of the MIPS ABI to Linux
In it's early days when Linux had relativly little software and Linux/MIPS an even smaller one the plan was to be compatible to the MIPS ABI. In practice this aim would have required numerous changes - how many wasn't obvious at all back in those days, so they never happened. Also System ABI defines interfaces without mandating if they're implemented in libraries or as syscalls, leaving the syscall interfaces upto the implementors. In reality this meant some RISC/os and IRIX kernel interfaces in a wild blend with the original Linux/i386 syscall interface became the Linux/MIPS syscall interface.
Today the MIPS ABI has largely been obsoleted. The former www.mips-abi.org site has been gone for several years, since all vendors of MIPS System V-based systems have dumped System V in favor of either Linux or Windows NT. The MIPS ABI heritage of Linux/MIPS is now more of a liability than useful, and occasionally a pain.
At the bottom line the only relevant parts that are left are the Tool Interface Standard Executable and Linking Format (ELF) Specification, dated May 1995, and portions of the System V Application Binary Interface: MIPS(r) Processor Supplement, 3rd Edition, dated February 1996. The most useful parts of this second document are the "Machine Interface" and "Function Calling Interface" sections, though portions of other sections are still relevant. Since those documents were created the ELF format has been enhanced in many ways by the developers of GNU binutils and libc.
See also
- SCO Developer Specs (o32 ABI)
- SGI's n32/n64 ABI documentation
- GCC's o64 ABI: an extension by GCC of the o32 ABI to 64-bits
- EABI: documentation on the EABI32 and EABI64 ABIs
