"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? 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? Thanks, Matthew
