On Fri, 19 May 2023, Jiaxun Yang wrote: > > I guess one can do it and still run FPXX software, but I fail to see what > > gain it provides. For FP32 it breaks things as accesses to odd-numbered > > FPRs will no longer get at the high part of a double value and for FP64 > > there are no MTHC1/MFHC1 instructions required to access the high part. > > Actually software may access the high part by SDC1/LDC1. I'm aware of that, but you'd need a new psABI variation really to handle such an arrangement. None of the existing FP32, FP64, FPXX handles it. > > What problem are you trying to solve? And how did you verify this patch? > > Was trying to deal a proprietary JIT software who want to enable FR1 via prctl > on Loongson-2F with 32 bit kernel. There may be a better way: rather than avoiding MTHC1/MFHC1, handle them in the FPU emulator where unavailable in FR=1 mode while leaving the rest to hardware. That would make regular FR64 software work. I'd expect such a JIT to have other issues with pre-R2 hardware though, with missing machine instructions. I had a similar situation a few years ago with FireFox's JIT making assumptions above the MIPS ISA level the piece of software was itself compiled for and opted for just disabling the JIT, as fixing FireFox and rebuilding it would be more effort than it was worth in my view. This might be the best way for you to move forward too, and I'm all but enthusiastic about adding a workaround in the kernel for a broken piece of proprietary user software. Sorry. Also I seem to remember there was a pitfall with running 32-bit software on pre-R2 hardware in the FR=1 mode, but maybe I'm making up things here. It's been so long since I last looked into this. In any case you do need to verify this somehow, like by running the math part of the glibc testsuite with o32 in the FR=1 mode on pre-R2 hardware. Running the GDB test suite to make sure ptrace(2) works fine with the new FPU configuration would make sense too. > > Currently all FPUs we support implement double and we require that, so no > > need to make this piece conditional (I would use IS_ENABLED otherwise, so > > as not to clutter the source with #ifdef), but `c->fpu_id' is also exposed > > to the user via ptrace(2), so this has to reflect hardware and not give a > > synthesized value. > > Alas, I thought R2030 class FPU does not have double? Since MIPS-IV spec > says SDC1 is introduced in MIPS II. There's no SDC1/LDC1, but the usual MIPS I FP machine instructions (of which there are fewer than in MIPS II, e.g. there's no SQRT.fmt or direct conversions) do support the double format/encoding. It's just that double FP data has to be transferred piecemeal; other supported operations will execute just fine. Otherwise the existence of the odd-numbered FPRs would make no sense in the first place. Plain single floating-point units are extremely rare, e.g. the R4650 has one (it does support CP0.Status.FR though, for 32 singles), and we do not support them (e.g. the R4650 has a simple base-bounds MMU only, no TLB). Another one is the R5900, but its FPU is not an IEEE 754 device even. Maciej
