Message-Id: <6B6F47AF-BA16-49FA-A959-7D3F064993DA@flygoat.com>
Date:   Sun, 21 May 2023 03:06:36 +0100
From:   Jiaxun Yang <jiaxun.yang@...goat.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Subject: Re: [PATCH] MIPS: Fix MIPS_O32_FP64_SUPPORT for 64bit CPUs before R2



> 2023年5月20日 21:32，Maciej W. Rozycki <macro@...am.me.uk> 写道：
> 
> 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

Powered by blists - more mailing lists