> "Jürgen Urban" <juergenur...@gmx.de>writes: > > > "Jürgen Urban" <juergenur...@gmx.de> writes: > > > > Hello Richard, > > > > > > > > > "Jürgen Urban" <juergenur...@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 > > 2.6.35.4. 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. Best regards Jürgen
