Hi Fredrik, > > I thought we agreed the R5900 FPU is unusable for regular Linux software > > and decided to go for full FPU emulation unconditionally. > > Yes, that's true, we are in agreement. I was unaware that the FPU emulation > was complete enough to cover all registers (not only a set of instructions). > Sorry about that. I will simply remove this patch then. The MIPS/Linux user ABI specifies a full architectural FPU, so not only we have to handle cases missing from hardware that cause an Unimplemented Operation exception, such as commonly operations on denormals, but (having not chosen, many years ago, to have the emulator in the userland) we have to emulate the whole FPU as well, for processors that do not have the unit at all. We are accurate enough even to throw SIGILL for otherwise handled FP instructions that are however supposed to be missing at the ISA level implemented by the CPU we are currently running on. We emulate a double unit, so operations on both double and single floating-point data types as well as corresponding fixed-point data types are supported. We do not emulate extra stuff though, such as operations on the paired single data type or MIPS-3D instructions. You have to access real FPU hardware to use them (and then you're in trouble if they cause an Unimplemented Operation exception). It would be nice if someone contributed the missing bits. > > Etc. -- can you reuse MIPS I code here, i.e. use S.D? GAS should be > > doing the right thing with `-march=r5900' (if not, then it has a bug). > > Possibly, I am somewhat unfamiliar with this area. So let's revisit this FPU > issue after the initial submission. Have a look at arch/mips/kernel/r2300_fpu.S; L.D and S.D are GAS macros which, depending on the architecture selected, expand to either LDC1 and SDC1 instructions or LWC1 and SWC1 instruction pairs, correctly ordered according to the endianness selected. You can probably use that file as it stands for the R5900 FPU, when you get to it. Maciej
