Difference between revisions of "MIPS ABI History"
m (SCO Developer Specs)
|Line 20:||Line 20:|
== See also ==
== See also ==
Revision as of 12:40, 17 February 2006
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 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.