"Jürgen Urban" <juergenur...@gmx.de> writes:
> Hello Richard,
>
> > "Jürgen Urban" <juergenur...@gmx.de> writes:
> > > The problem happens with the r5900 hard float configurations, e.g.:
> > > configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
> > > --with-arch=r5900
> > > I created the attached patch which fixes this problem for r5900 and
> > > another problem explained later.
> > > The fixed code generates the following code which should be correct
> > > (mipsr5900el-ps2-elf):
> > >
> > > 00105440 <__extendsfdf2>:
> > > 105440: 27bdffc8 addiu sp,sp,-56
> > > 105444: 27a40028 addiu a0,sp,40
> > > 105448: 27a50018 addiu a1,sp,24
> > > 10544c: afbf0034 sw ra,52(sp)
> > > 105450: 0c0417b5 jal 105ed4 <__unpack_f>
> > > 105454: e7ac0028 swc1 $f12,40(sp)
> > > 105458: 8fa20024 lw v0,36(sp)
> > > 10545c: 8fa40018 lw a0,24(sp)
> > > 105460: 8fa5001c lw a1,28(sp)
> > > 105464: 8fa60020 lw a2,32(sp)
> > > 105468: 00021882 srl v1,v0,0x2
> > > 10546c: 00021780 sll v0,v0,0x1e
> > > 105470: afa20010 sw v0,16(sp)
> > > 105474: 0c041789 jal 105e24 <__make_dp>
> > > 105478: afa30014 sw v1,20(sp)
> > > 10547c: 8fbf0034 lw ra,52(sp)
> > > 105480: 03e00008 jr ra
> > > 105484: 27bd0038 addiu sp,sp,56
> > >
> > > The default targets mipsr5900el and mips64r5900el are not affected by
> > > the problem, because soft float is the default.
> > >
> > > It also seems that the same problem occurs with the following
> configuration:
> > > configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
> > > I expected that this combination should work and a problem should
> > > already be detected. Can somebody confirm that the problem also occurs
> > > with default mipsel?
> >
> > Although that configuration is in theory supported by GCC (said like that
> > because I don't know the state of the glibc support for single-float),
> > I don't think anyone uses it for any target other than r5900. But you're
> > right that this is a --with-fpu=single thing rather than an r5900 thing,
> > so I don't think the patch is correct. It should be keyed off whether
> > the target is single-float or double-float, which you can test by
> > checking whether the preprocessor macro __mips_single_float is defined.
>
> Checking these macros seem to be too late, because it needs to be known at
> configure time and not at build time. The libgcc doesn't seem to be very
I believe the suggestion is to add some code to configure.ac to detect a
single-float configuration like the hard-float is detected and update your
patch accordingly with no need to reference r5900 at all:
case ${host} in
mips*-*-*)
AC_CACHE_CHECK([whether the target is hard-float],
[libgcc_cv_mips_hard_float],
[AC_COMPILE_IFELSE(
[#ifndef __mips_hard_float
#error FOO
#endif],
[libgcc_cv_mips_hard_float=yes],
[libgcc_cv_mips_hard_float=no])])
esac
> flexible. It doesn't seem to provide different libraries for single and
Single and double float would need to be supported as multilibs, it is generally
assumed that all libraries in the same folder follow a compatible ABI. Single
and double float ABIs are inherently incompatible.
> double float. The Linux kernel on the PS2 has support to switch between
> single and double float. For single float the hardware FPU is used and for
Just to confirm... The kernel has special handling for an ELF using r5900 arch
and then checks to see if it is single or double float? 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.
> 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.
Regards,
Matthew
