> On Tue, 2 Mar 2021, YunQiang Su wrote: > > > The MIPS FPU may have 2 mode: > > FR=0: MIPS I style, odd-FPR can only be single, > > and even-FPR can be double. > > Depending on the ISA level FR=0 may or may not allow single arithmetic with > odd-numbered FPRs. Compare the FP64A ABI. > > > FR=1: all 32 FPR can be double. > > I think it's best to describe the FR=0 mode as one where the FP registers are > 32-bit and the FR=1 mode as one where the FP registers are 64-bit (this mode > is also needed for the paired-single format). See: > > <https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlin > king#1._Introduction> > Thank you. I will update it. > > The binary may have 3 mode: > > FP32: can only work with FR=0 mode > > FPXX: can work with both FR=0 and FR=1 mode. > > FP64: can only work with FR=1 mode > > > > Some binary, for example the output of golang, may be mark as FPXX, > > while in fact they are FP32. > > > > Currently, FR=1 mode is used for all FPXX binary, it makes some wrong > > behivour of the binaries. Since FPXX binary can work with both FR=1 > > and FR=0, we force it to use FR=0. > > I think you need to document here what we discussed, that is the linker bug > exposed in the context of FPXX annotation by legacy modules that lack FP > mode annotation, which is the underlying problem. I will do it. > > > v5->v6: > > Rollback to V3, aka remove config option. > > You can't reuse v3 as it stands because it breaks R6 as we previously > discussed. You need to tell R6 and earlier ISAs apart and set the FR bit > accordingly. > It won't break r6, as all of r6 binary is FP64, and on r6 `frdefault' is always false, and `fr1' is always true. It won't trigger this mode switch. Oh, you are right, there may be a case that to run legacy app on r6 CPU. For this case, on r6, we need to set the CPU to FRE mode. > It would be more proper I suppose if we actually checked at the boot time > whether the bit is writable, just like we handle NAN2008, but I don't see it as > a prerequisite for this workaround since we currently don't do this either (it > would also be good to check if the FP emulation code gets the read-only FR bit > right for R6 for FPU-less operation). > Check writable is not needed here. > Also you need to put the history in the comment section and not the commit > description, so that the change can be directly applied and does not have to > be hand-edited by the maintainer. You don't want to overload him with > mechanical work. > Ok, I will add more comment. > Maciej
