This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking


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:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]