This is the mail archive of the
mailing list for the GCC project.
Aw: RE: Re: [MIPS r5900] libgcc floating point fixes
- From: "JÃrgen Urban" <JuergenUrban at gmx dot de>
- To: "Matthew Fortune" <Matthew dot Fortune at imgtec dot com>
- 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, 28 Jul 2014 00:02:28 +0200
- Subject: Aw: 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>, <6D39441BF12EF246A7ABCE6654B0235320EB02A8 at LEMAIL01 dot le dot imgtec dot org>
- Sensitivity: Normal
> "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
> > exist.
> > > 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
> > 188.8.131.52. 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?
Currently it just enables or disables the FPU. When FPU is disabled the software emulation is used.
> I'm afraid I donât know the significance of the sync.p.
> > > > double the FPU emulator gets activated. Currently it only checks whether
> > the
> > > > 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
> > to
> > > > 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
> > to
> > > > be read by the kernel when starting a ELF file. This way it would also
> > be
> > >
> > > 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
> > double-float
> > > ABI extensions. You will be able to directly hang off the changes once I
> > commit
> > > (testing is taking some time). There should be no need for extra changes
> > to
> > > 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
> > as
> > > > 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
> > treated
> > > > > as normal numbers.
> > > >
> > > > The code looked like it uses the configured floating point configuration
> > for
> > > > hard float, but you are right the conversion is not working in these
> > cases.
> > > >
> > > > I think there is no problem with the second part of the patch which
> > disables
> > > > 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
> > the
> > > double-precision ABIs are assumed to be the only ones used in Linux in a
> > number
> > > 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
> > point.
> 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
> > n32.
> I didn't quite follow why you specifically say n32 in the last sentence...
> What is harder to fix about n32 than o32?
"-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and dmfc1. So I can't compile it for r5900. When I disable it, I get internal compiler errors.