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
