> 2023年5月20日 21:32，Maciej W. Rozycki <macro@xxxxxxxxxxx> 写道： > > 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. Thanks for all those information. I was just entertaining by poking around some old software blobs from Loongson so I’d give up upstreaming those changes. My limited test works fine with this patch though. - Jiaxun > > 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
