From: "Maciej W. Rozycki" <macro@wdc.com>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: "Serge Semin" <Sergey.Semin@baikalelectronics.ru>,
"Serge Semin" <fancer.lancer@gmail.com>,
linux-mips@vger.kernel.org,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Paul Burton" <paulburton@kernel.org>,
"Huacai Chen" <chenhc@lemote.com>,
"Zhou Yanjie" <zhouyanjie@zoho.com>,
"周琰杰 (Zhou Yanjie)" <zhouyanjie@wanyeetech.com>,
"Liangliang Huang" <huanglllzu@gmail.com>,
linux-kernel@vger.kernel.org,
"Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] MIPS: Provide Kconfig option for default IEEE754 conformance mode
Date: Wed, 5 Aug 2020 20:30:17 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.21.2008051850390.24175@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <ceb71bef-b3e6-68ce-df80-bcff92085e66@flygoat.com>
On Mon, 3 Aug 2020, Jiaxun Yang wrote:
> > Well, originally plans were there to have NaN interlinking implemented
> > and no such mess or desire for hacks like one here would result. Cf.:
> >
> > <https://gcc.gnu.org/ml/gcc/2015-11/msg00068.html>,
> > <https://gcc.gnu.org/ml/gcc/2016-05/msg00137.html>,
> >
> > and then:
> >
> > <https://lkml.org/lkml/2015/11/16/386>,
> > <https://sourceware.org/ml/libc-alpha/2015-11/msg00485.html>,
> > <https://sourceware.org/ml/binutils/2015-11/msg00170.html>,
> > <https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03241.html>.
> >
> > You could well pick this work up and complete it if you like. Final
> > conclusions for further work were made here:
> >
> > <https://gcc.gnu.org/ml/gcc/2016-11/msg00027.html>,
> > <https://gcc.gnu.org/ml/gcc/2017-08/msg00260.html>,
> > <https://gcc.gnu.org/ml/gcc/2017-10/msg00142.html>.
> >
> > In the relaxed mode math programs may produce wrong results unless you
> > rebuild all your software for the correct NaN mode for the hardware used
>
> Unfortunately most of the hardware guys didn't understood the difficulty
> here.
> They decided to implement their hardware (P5600 & LS3A4000) as NaN2008 only.
Sadly we (the software group) have lost the battle with the hardware
group for the architecture to have FCSR.NAN2008 at least optionally
writable, and the feature was subsequently removed from R5 on, along with
the writability of FCSR.ABS2008 and the FCSR.MAC2008 bit altogether.
Still R3 did permit those bits to be r/w (check rev. 3.50 of the
architecture spec), which is why I implemented them as such in our FP
emulation and also QEMU (although I need to note that a competing QEMU
implementation was pushed upstream behind my back, which I believe wasn't
as complete as mine, so this part may or may not have been implemented).
> I was thinking about let Kernel drop SIGFPE exception was caused by
> mismatched NaN,
> as most applications don't rely on signaling NaN, but it is still a
> dirty hack. Not a good
> idea in general.
I think you cannot reliably send SIGFPE, because hardware does not trap
on what it considers a qNaN.
The interlinking effort was there to let individual pieces of software
that have various requirements for NaNs, or do not use FP at all, to use a
set of rules for possibly being allowed to run on incompatible hardware or
loaded together by the dynamic loader. For example there was a mode
specified where all NaNs were silently treated as qNaNs regardless of the
hardware interpretation of a specific encoding.
I maintain this is the way to move forward, and if you are serious about
keeping the architecture alive, then I strongly recommend to upstream the
implementation, possibly based on my patches previously published,
although as indicated in the discussion referred there have been design
issues observed, which mean a certain amount of rework will be required,
first on the spec, and then the implementation.
FWIW,
Maciej
next prev parent reply other threads:[~2020-08-05 19:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 4:10 [PATCH] MIPS: Provide Kconfig option for default IEEE754 conformance mode Jiaxun Yang
2020-07-31 6:17 ` Serge Semin
2020-07-31 6:54 ` Huacai Chen
2020-08-02 21:46 ` Maciej W. Rozycki
2020-08-03 9:01 ` Jiaxun Yang
2020-08-05 19:30 ` Maciej W. Rozycki [this message]
2020-08-05 20:49 ` Zhou Yanjie
2020-07-31 8:33 ` WANG Xuerui
2020-07-31 4:11 Jiaxun Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.21.2008051850390.24175@redsun52.ssa.fujisawa.hgst.com \
--to=macro@wdc.com \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=chenhc@lemote.com \
--cc=fancer.lancer@gmail.com \
--cc=huanglllzu@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=paulburton@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=zhouyanjie@wanyeetech.com \
--cc=zhouyanjie@zoho.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).