MIPS ABI Project
MIPS ABI Project
What we are trying to accomplish
Initially we want to update the o32 abi to reflect current reality.
Some extensions to the original o32 abi are listed as follows.
- MIPS32 release 2 ISA allows a 64-bit FPU and 32 64-bit FP registers.
Currently, bare-iron programs can support this feature through a GCC option "-mfp64".
However, this feature affects the Linux kernel for saving and restoring 32 64-bit FP registers. Theoretically, it is doable. But we haven't decided to do it.
- New relocation types are created for MIPS16.
- New relocation types are created for microMIPS.
How many ABIs currently are there for MIPS
- o32 - Developed by MIPS
- n32 - Developed by MIPS/SGI
- n64 - Developed by MIPS/SGI
- NUBI - Tries to unify 16/32/64 bit architectures. Was it ever implemented?
- o64 - Developed by Gnu?
- eabi - Developed by Gnu
- eabi - Developed by GreenHills
Do we need a new one
This is good place for controversy!
- The *only* person scheduled right now to do any work is Don for some prototyping that we can do now with the current o32 ABI (obviously non compliant, but necessary for core development and hw vs sw implementations and implications). Chris, you might need to be involved in some of these discussions with Don, Wayne, and Suds.
- Prototyping of the bits that should eventually be in the new ABI (the bits we can to add into the current ABIs) has an initial guess of a six month duration with Don, Chris, and I working with Suds and his team to determine trade offs etc.
- The gating item on the development of the new ABI is the changes to the memory map for the cores, the funding of the work., and a decision on how much of the new ABI is back-ported into the existing ABIs that will have a minimal impact on the existing.
- Then a *massive* amount of work will need to be done that includes 5 people at Mentor, buy-in from NetLogic and the like (we have an external ABI team waiting in the wings), all parts of GCC and LLVM (teams here and at RT-RK), and essentially, changes to all of our software offerings, as well as third parties. The stake in the ground for the new ABI (minus the memory map changes) is one calendar year and that's slightly aggressive. I *have* not included the necessary time from the sw-stacks or simulator teams - they might increase the time line - essentially, this will be an engineering wide project.
PC Relative Branches
Here is a link to a study done in-house on ABI improvements in terms of pc-relative instructions.
What are the components of an ABI
The following is lifted and edited from the MIPS ABIs Described document:
This document describes standards (‘‘ABIs’’) to which compilation systems should adhere to achieve the following goals, which are ordered approximately by how challenging they are:
- Inter-calling :
- A binary program built with one compiler should be able to call a subroutine defined in another (so long as address resolution problems are solved).
- The standards relevant to this are called the ‘‘calling conventions’’; they describe how subroutines pass parameters, return values, and co-operate to share the register set and stack resources.
- Interlinkable :
- Object files built with one compiler can be linked successfully with those produced by another.
- The standard relevant to this is the object code definition, in particular the definition of symbols and relocation mechanisms.
- Runnable :
- A binary produced with a compliant toolkit can be successfully executed on a compliant OS (in particular we’re interested in versions of the Linux OS). The program must first be compatible with the semantics of the library and/or system calls provided by the OS, of course; the ABI says nothing about that.
- This requires standards regulating the use of run-time linked system library code. Most of this stuff is defined by related standards such as the overarching [SVR4 ABI], to which all subsequent ABI manuals are footnotes.
- Debuggable :
- More conventions and standards are required before a program build with a toolkit can be successfully debugged. People quite often use ‘‘foreign’’ debuggers with code built with the GNU toolchain, for example.
- Profilable :
- Where available, code profilers have their own requirements - related to but not identical to those of debuggers.
File:007-4658-001.pdf : MIPS Technologies/SGI - 64-bit ELF Object File Specification (Draft Version 2.5)
File:007-2816-005-1.pdf : SGI - MIPSproTM N32 ABI Handbook (2002)
File:MD00305-2B-ABIDESC-SPC-01.03.pdf : MIPS Technologies - MIPS ABIs Described (2002/12/02)
File:Mipsabi.pdf : SCO - SYSTEM V APPLICATION BINARY INTERFACE MIPS® RISC Processor Supplement 3rd Edition (1996)
File:MD00438-2C-NUBIDESC-SPC-00.20-1.pdf : MIPS Technologies - NUBI - A Revised ABI for the MIPS® Architecture (2005/10/11)
File:EABI spec.pdf RedHat - MIPS EABI documentation
File:O64 spec.pdf GNU : MIPS O64 Application Binary Interface for GCC
File:ELF Format.pdf Elf Format
File:MIPS ABI.pdf System V MIPS Processor Supplement (1991)
We also have a hard copy of the 1997 MIPS ABI Group's "MIPS ABI Specification" I cannot find an e-copy as of yet.
- Is this the documentation for MIPS TLS (Thread Local Storage) support? link
- Where are these described?
- R_MIPS_GLOB_DAT - link