Matthew Fortune <matthew.fort...@imgtec.com> writes: > 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
Looks good to me. It'll be interesting to see whether making the odd-numbered call-saved-in-fr0 registers available for frx pays off or whether it ends up being better to avoid them. I understand the need to deprecate the current -mgp32 -mfp64 behaviour. I don't think we should deprecate -mfp64 itself though. Instead, why not keep -mfp32 as meaning FR0, -mfp64 meaning FR1 and add -mfpxx for modeless? So rather than deprecating the -mgp32 -mfp64 combination and adding -mfr, we'd just make -mgp32 -mfp64 generate the new FR1 form in which the odd-numbered registers are call-clobbered rather than the old form in which they were call-saved. AIUI the old form never really worked reliably due to things like newlib's setjmp not preserving the odd-numbered registers, so it doesn't seem worth keeping around. Also, the old form is identified by the GNU attribute (4, 4) so it'd be easy for the linker to reject links between the old and the new form. The corresponding asm would then be ".set fp=xx". Either way, a new .set option would be better than a specific .fr directive because it gives you access to the option stack (".set push"/".set pop"). I'm not sure about: If an assembly directive is seen prior to the start of the text section then this modifies the default mode for the module. This isn't how any of the existing options work and I think the inconsistency would be confusing. It also means that if the first function in a file happens to force a local mode (e.g. because it's an ifunc implementation) then you'd have to remember to write: .fr x .fr 1 so that the first sets the mode for the module and the second sets it for the first function. The different treatment of the two lines wouldn't be obvious at first glance. How about instead having a separate directive that explicitly sets the global value of an option? I.e. something like ".module", taking the same options as ".set". Better names welcome. :-) The scheme allows an ifunc to request a mode and effectively gives the choice to the firstcomer. Every other ifunc then has to live with the choice. I don't think that's a good idea, since the order that ifuncs are called isn't well-defined or under direct user control. Since ifuncs would have to live with a choice made by other ifuncs, in practice they must all be prepared to deal with FR=1 if linked into a fully-modeless or FR1 program, and to deal with FR=0 if linked into a fully-modeless or FR0 program. So IMO the dynamic linker should simply set FR=1 for modeless programs if the hardware supports it and set it to 0 for modeless programs otherwise, like you say in the first paragraph of 9.4. You allow the mode to be changed midexecution if a new FR0 or FR1 object is loaded. Is it really worth supporting that though? It has the same problem as the ifuncs: once you've dlopen()ed an object, you fix the mode for the whole program, even after the dlclose(). Unless we know of specific cases where this is needed, maybe it would be safer to fix the mode before execution based on DT_NEEDED libraries and allow the mode of modeless programs to be overridden by an environment variable. If we do end up using ELF flags then maybe adding two new EF_MIPS_ABI enums would be better. It's more likely to be trapped by old loaders and avoids eating up those precious remaining bits. You didn't say specifically how a static program's crt code would know whether it was linked as modeless or in a specific FR mode. Maybe the linker could define a special hidden symbol? Thanks, Richard