Hi Richard/all,
The spec on:
https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking has
been updated and attempts to account for all the feedback. Not everything has
been possible to simplify/rework as requested but I believe I have managed to
address many points cleanly.
Sections 9 and 10 contain pretty much all the changes and a fresh read is
better than me attempting to summarise. All the attributes, flags, etc are now
defined with specific values and specific comments regarding kernel support for
UFR have been added.
I have an implementation of everything except the program loader which I will
post to ensure the overall approach in code is acceptable. I'll do this on each
project's list appropriately. Since I am only just starting testing I have no
test cases to offer alongside the patches currently, I will be working on that
next. I'm deferring writing all the tests in case the implementation/behaviour
changes, hence initial review for now.
The implementation in GCC relies on LRA due to the way in which caller-save is
handled. A patch to enable LRA and fix all regressions is being developed
concurrently and will be posted ready for stage 1.
Let me know if there is any feedback on the updated spec.
I'm afraid the last aspect we discussed is still a point of contention :-) I'm
sure we'll get there though. I've added more comments inline below:
Richard Sandiford <rdsandif...@googlemail.com> writes:
> Matthew Fortune <matthew.fort...@imgtec.com> writes:
> >> I think instead we should have a configuration switch that allows a
> >> particular -mfp option to be inserted alongside -mabi=32 if no
> >> explicit -mfp is given. This is how most --with options work. Maybe
> >> --with-fp- 32={32|64|xx}? Specific triples could set a default value
> if they like.
> >> E.g. the MTI, SDE and mipsisa* ones would probably want to default to
> >> -- with-32-fp=xx. Triples aimed at MIPS IV and below would stay as
> >> they are. (MIPS IV is sometimes used with -mabi=32.)
> >>
> >> --with-fp-32 isn't the greatest name but is at least consistent with
> >> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
> >> breaking consistency is better though.
> >
> > Tying the use of fpxx by default to a configure time setting is OK
> > with me. When enabled it would still have to follow the rules as
> > defined in the design in that it can only apply to architectures that
> > can support the variant.
>
> Right. It's really equivalent to putting the -mfp on every command line
> that doesn't have one.
>
> > Currently that means everything but mips1.
>
> Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
>
> > I'm not sure this is the same as tying an ABI to an architecture as
> > both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> > switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
> > related setting.
>
> What I meant is that -march= and -mips shouldn't imply a different -mfp
> setting. The -mfp setting should be self-contained and it should be an
> error if the architecture isn't compatible.
>
> We might be in violent agreement here :-) Like I say, I was just a bit
> worried by the earlier -mips32r2 thing because there was a time when a -
> mips option really could imply things like -mabi, -mgp and -mfp.
>
> --with-o32-fp would be OK with me. I'm just worried about the ABI being
> spelt differently from -mabi=, but there's probably no perfect
> alternative.
I'd like to encourage the perspective that -mfp* options do not lead to a
different ABI in the same sense that other variations do. While it is true that
the calling conventions and code generation rules vary, 2 out of 3 combinations
of -mfp32 -mfpxx and -mfp64 with -mabi=o32 are link compatible. The
introduction of the modeless O32 ABI is intended to remove the part of the O32
definition that says 'FR=0' and hence the architecture then gets to dictate
this and the generated code is still O32. It is true today that we have several
architectures that mandate FR=0, some that cannot support fpxx and some that
can support all fp* variations. I see nothing preventing the future having an
architecture only supporting FR=1 though which we should also think about. When
considering such a scenario it would be highly desirable for the following to
just work as I believe architectural restrictions should be accounted for when
designing default options. If the architecture gives no choice then it should
just work IMO:
Some ideas (speculating that someone builds a core called mips_n with only
FR=1):
--with-o32-fp=32
mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
mips-*-gcc -march=mips2 fp.c ==> generates fp32 code
mips-*-gcc -march=mips32r2 fp.c ==> generates fp32 code
mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
--with-o32-fp=xx
mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
mips-*-gcc -march=mips2 fp.c ==> generates fpxx code
mips-*-gcc -march=mips32r2 fp.c ==> generates fpxx code
mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
--with-o32-fp=64
mips-*-gcc -march=mips1 fp.c ==> generates fp32 code
mips-*-gcc -march=mips2 fp.c ==> generates fpxx code
mips-*-gcc -march=mips32r2 fp.c ==> generates fp64 code
mips-*-gcc -march=mips32r2 -mfp64 fp.c ==> generates fp64 code
mips-*-gcc -march=mips32r2 -mfpxx fp.c ==> generates fpxx code
mips-*-gcc -march=mips_n fp.c ==> generates fp64 code
With these defaults, the closest supported ABI is used for each architecture
based on the --with-o32-fp build option. The only one I really care about is
the middle one as it makes full use of the O32 FPXX ABI without a user needing
to account for arch restrictions.
I'm interested to understand the kind of problems that have occurred in the
past with setting defaults based on architecture. GCC does currently at least
select default ABI based on 32-bit vs 64-bit arch and this would be an
extension of that.
Is there any middle ground on this point?
Regards,
Matthew
