[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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