This is the mail archive of the
mailing list for the GCC project.
RE: Re: [MIPS r5900] libgcc floating point fixes
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: "JÃrgen Urban" <JuergenUrban at gmx dot de>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 21 Jul 2014 06:22:09 +0000
- Subject: RE: Re: [MIPS r5900] libgcc floating point fixes
- Authentication-results: sourceware.org; auth=none
- References: <trinity-37357c54-bec5-48dd-bd67-0fb25e238bd3-1402862904892 at 3capp-gmx-bs04>, <87lhrw1bli dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <trinity-a1d0b6c9-8b19-47db-a4f7-3b4ac97e11cf-1405710022356 at 3capp-gmx-bs32>, <6D39441BF12EF246A7ABCE6654B0235320EAFEE7 at LEMAIL01 dot le dot imgtec dot org> <trinity-23cffbb1-6d7e-45f8-acb0-eb58d6b30fbf-1405872012472 at 3capp-gmx-bs18>
"JÃrgen Urban" <JuergenUrban@gmx.de>writes:
> > "JÃrgen Urban" <JuergenUrban@gmx.de> writes:
> > > Hello Richard,
> > >
> > > > "JÃrgen Urban" <JuergenUrban@gmx.de> writes:
> > Is this something you
> > have recently developed outside of the mainline kernel or does it already
> > I'm not aware of such logic in the MIPS kernel yet.
> Yes, this is developed in my kernel which currently is still based on Linux
> 220.127.116.11. I added a TIF_R5900FPU flag to thread_info.h. I plan that this
> will get part of the mainline kernel. As the patch is too large to get
> accepted, I need to change the binutils, so that sync.p will be added after
> or before the right instruction automatically.
Is the TIF_R5900FPU flag to do something more than just change the register
model used by the FPU emulator or does it do something more/less? I'm afraid
I donât know the significance of the sync.p.
> > > double the FPU emulator gets activated. Currently it only checks whether
> > > architecture is mips r5900 or not. For non r5900 the FPU emulator is
> > > activated. It seems that we also need to add something to the ELF file
> > > specify the 32 bit or 64 bit for float. It would be good when it is not
> at a
> > > so complicated position as the soft vs hard float flag, because it needs
> > > be read by the kernel when starting a ELF file. This way it would also
> > I have a series of patches that will add this kind of support to the MIPS
> > ABI in the coming weeks for similar reasons but relating to O32 and
> > ABI extensions. You will be able to directly hang off the changes once I
> > (testing is taking some time). There should be no need for extra changes
> > gcc or binutils to get the information you need. Kernel changes to respond
> > to new ABI information are also in progress and will be easily extendable.
> > > possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same
> > > r5900, but the FPU is 64 bit and compliant to IEEE 754.
> > >
> > > > Note that this won't really be correct for r5900 anyway because of its
> > > > non-IEEE FPU. E.g. the soft-float routines will treat 0x7f800000 as
> > > > infinity and 0x7fffffff as a NaN, whereas for r5900 they should be
> > > > as normal numbers.
> > >
> > > The code looked like it uses the configured floating point configuration
> > > hard float, but you are right the conversion is not working in these
> > >
> > > I think there is no problem with the second part of the patch which
> > > t-mips16 for r5900. So could you commit the last part of the patch?
> > Are you looking to add support for a single-float FPU to a number of
> > packages as part of this? One thing that comes to mind would be libffi but
> > double-precision ABIs are assumed to be the only ones used in Linux in a
> > of places. Just trying to get a feel for your end goal out of curiosity.
> The libffi doesn't look like that there is a change needed for floating
Libffi and most other hand crafted code for linux are written to follow the
standard double-precision O32/N32 ABI. The single-precision variants are
link-incompatible as they change the calling convention. I.e. when you pass
a double-precision value using a single-precision calling-convention then it
gets passed in GPRs instead of FPRs.
> It is possible that it needs a change for TImode or for 2 or 3 of the other
> co-processors which are currently not under discussion.
> The long term plan is to have 32 bit floating point operations compliant to
> IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and
> the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and
> not in any high level library.
Due to the calling convention change you won't be able to restrict the work
to just the toolchain and kernel. MIPS linux theoretically supports two ABI
extensions 'hard-float (double-precision)' and soft-float. I have a feeling
that the soft-float extension is not supported everywhere but may be a better
start point for what you want to achieve, i.e. use a soft-float calling
convention but add support for using FPU instructions at the same time. This
would be akin to arm's softfp float-abi.
> Fixes for high level libraries should also be
> high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a
> different package which is specific for MIPS. The type double should stay
> double and is handled without a problem when the FPU is 32 bit in ABI o32.
> The problem is only with the single/double conversion functions and the ABI
I didn't quite follow why you specifically say n32 in the last sentence...
What is harder to fix about n32 than o32?