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 theABI acronym and a defined binding to object code with the AT&T-inspiredUnixSystem V document which is rooted withSVR4.

That process had coalesced as early as1990 into much of theo32 ABI which is widely used today. By about1994 the ABI was expanded to encompass position-independent code and theELF object codesyntax, and therehave 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 real64-bit computing. SGI defined a 64-bit ABI calledn64 suitable for the largest applications; and then - belatedlyrealising that n64's 64-bit pointer and long types bloated programs and caused portability problems to manyapplications which didn't need them - produced the very similar standardn32, which differs primarily in having32-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 o32forever: but escaping from o32 couldnoticeably improve performance and ease various kinds of compatibility. So MIPS Technologies' has a proposal calledNUBI 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 someRISC/os andIRIX 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 theTool Interface StandardExecutable and Linking Format (ELF) Specification, dated May1995, and portions of theSystem V Application Binary Interface: MIPS(r) Processor Supplement, 3rd Edition, dated February1996. 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 GNUbinutils andlibc.

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