This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Date: Fri, 21 Feb 2014 16:55:09 +0000
- Subject: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
- Authentication-results: sourceware.org; auth=none
All,
Imagination Technologies would like to introduce the design of an O32 ABI extension for MIPS to allow it to be used in conjunction with MIPS FPUs having 64-bit floating-point registers. This is a wide-reaching design that involves changes to all components of the MIPS toolchain it is being posted to GCC first and will progress on to other tools. This ABI extension is compatible with the existing O32 ABI definition and will not require the introduction of new build variants (multilibs).
The design document is relatively large and has been placed on the MIPS Compiler Team wiki to facilitate review:
http://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
The introductory paragraph is copied below:
---
MIPS ABIs have been adjusted many times as the architecture has evolved, resulting in the introduction of incompatible ABI variants. Current architectural changes lead us to review the state of the O32 ABI and evaluate whether the existing ABI can be made more compatible with current and future extensions.
The three primary reasons for extending the current O32 ABI are the introduction of the MSA ASE, the desire to exploit the FR=1 mode of current FPUs and the potential for future architectures to demand that floating point units run in the 'FR=1' mode.
For the avoidance of doubt:
* The FR=0 mode describes an FPU where we consider registers to be constructed of 32-bit parts and (depending on architecture revision) there are either 16 or 32 single-precision registers and 16 double-precision registers. The double-precision registers exist at even indices and their upper half exists in the odd indices.
* The FR=1 mode describes an FPU with 32 64-bit registers. All registers can be used for either single or double-precision data.
* The MSA ASE requires the FR=1 mode
---
All aspects of this design are open for discussion but, in particular, feedback and suggestions on the following areas are welcome:
* The mechanism in which we mark the mode requirements of binaries (ELF flags vs 'other')
* The mechanism in which mode requirements are conveyed from a program loader to a running program/dynamic linker.
Regards,
Matthew