From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dan Malek <d6malek@digitaldans.com>
Cc: Xie Shaohui-B21989 <B21989@freescale.com>,
Liu Qiang-B32616 <B32616@freescale.com>,
Zang Roy-R61911 <r61911@freescale.com>,
Timur Tabi <timur@tabi.org>,
"tiejun.chen" <tiejun.chen@windriver.com>,
David Laight <David.Laight@ACULAB.COM>,
Fleming Andy-AFLEMING <afleming@freescale.com>,
Bhushan Bharat-R65777 <R65777@freescale.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: fsqrt
Date: Sat, 08 Jun 2013 14:31:08 +1000 [thread overview]
Message-ID: <1370665868.3766.451.camel@pasglop> (raw)
In-Reply-To: <4A771AC5-37F2-4EC2-A733-52FFAAAB3C92@digitaldans.com>
On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote:
> Hi Ben.
>
> On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
> > The question is whether this is still relevant ?
>
> The only answer I could provide is that it's dependent upon the
> libraries and how the distributions are built. It's also dependent
> upon processors with hardware FP that don't implement all instructions
> in hardware (who had that bright idea? :)) If distributions are fully
> all soft-fp in user space or all hardware FP, it removes the one
> reason that started the whole partial emulation option.
I'm not questioning the relevance of math-emu as a whole, but of the
tiny subset which is duplicated in math-emu and softemu8xx, which
emulates only load/stores/fmr.
If userspace is built with hard FP it is likely to use more than just
those handful of instructions...
> > … And if the answer is
> > yes,
>
> There are multiple options, but I believe they are solved today. One
> is the libraries coded with hardware load/store that are used by
> soft-fp, another is hardware FP that doesn't implement all
> instructions in hardware (which it seems is the basis of this thread,
> although I thought was already solved).
Yes, it's indeed the basis of that thread, and yes, I though it was
already solved as well but unless I missed something it is not, because
the current Program Check handler calls do_mathemu without first
flushing the hard FP state into the thread_struct.
However it's quite possible (I'll test when I get back to the office)
that this it the only fix necessary, which is a one liner, to make
CONFIG_MATH_EMULATION work just fine in that case.
> The variation here is that in the first case you have to read/write
> user space soft-fp stack "registers," while in the latter you
> read/write real FP registers.
We never do any "user space soft-fp stack registers" handling in the
kernel. If we use full math emu (ie, no FP at all in HW), we simply use
the normal thread_struct storage of FPRs to store the "virtual" user FP
regs used by the emulation.
If use space uses full soft-fp (ie, -msoft-float), we should never see
any of it in the kernel.
> There used to be the third variation where the stack was allocated
> and the emulation had to write both places due to compiler function
> APIs or optimizations. Of course, then there is the full-up kernel
> emulation where hardware is entirely lacking.
I don't know anything about that "3rd option", it certainly doesn't have
any kernel impact that I can see :-) Full up emulation is of course
still there.
> > … we still want that "minimum" emulation of load/stores/fmr as an
> > option, is there any reason why we can't replace the one in
> softemu8xx
> > with the existing (and unused) equivalent in do_mathemu ?
>
> It appears to me that 8xx custom code can be removed. I guess I
> should try to boot it up, if anyone even cares these days. :)
Thanks,
Cheers,
Ben.
next prev parent reply other threads:[~2013-06-08 4:31 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-16 4:47 SATA FSL and upstreaming Benjamin Herrenschmidt
2013-05-16 5:45 ` Benjamin Herrenschmidt
2013-05-16 5:55 ` tiejun.chen
2013-05-16 6:06 ` Benjamin Herrenschmidt
2013-05-16 5:59 ` Zang Roy-R61911
2013-05-16 6:01 ` Bhushan Bharat-R65777
2013-05-16 6:05 ` Zang Roy-R61911
2013-05-16 6:09 ` Benjamin Herrenschmidt
2013-05-16 6:17 ` tiejun.chen
2013-05-16 6:20 ` Zang Roy-R61911
2013-05-16 6:25 ` tiejun.chen
2013-05-16 7:20 ` Zang Roy-R61911
2013-05-16 6:26 ` Benjamin Herrenschmidt
2013-05-16 6:21 ` Benjamin Herrenschmidt
2013-05-16 6:35 ` tiejun.chen
2013-05-16 6:37 ` Zang Roy-R61911
2013-05-16 6:40 ` Benjamin Herrenschmidt
2013-05-16 6:43 ` tiejun.chen
2013-05-16 6:48 ` Bhushan Bharat-R65777
2013-05-16 6:49 ` Zang Roy-R61911
2013-05-16 6:53 ` Benjamin Herrenschmidt
2013-05-16 6:56 ` tiejun.chen
2013-05-16 7:01 ` Zang Roy-R61911
2013-05-16 7:05 ` Benjamin Herrenschmidt
2013-05-16 7:13 ` Bhushan Bharat-R65777
2013-05-16 7:26 ` Benjamin Herrenschmidt
2013-05-16 7:20 ` Xie Shaohui-B21989
2013-05-16 7:25 ` Bhushan Bharat-R65777
2013-05-16 6:59 ` Benjamin Herrenschmidt
2013-05-16 7:17 ` Zang Roy-R61911
2013-05-16 6:52 ` Benjamin Herrenschmidt
2013-05-16 14:56 ` Timur Tabi
2013-06-07 3:52 ` Benjamin Herrenschmidt
2013-06-07 4:39 ` Benjamin Herrenschmidt
2013-06-07 4:45 ` Zang Roy-R61911
2013-06-07 4:47 ` Benjamin Herrenschmidt
2013-06-07 4:50 ` Zang Roy-R61911
2013-06-07 7:41 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:45 ` fsqrt Zang Roy-R61911
2013-06-07 8:53 ` fsqrt Benjamin Herrenschmidt
2013-06-07 8:59 ` fsqrt Benjamin Herrenschmidt
2013-06-07 10:48 ` fsqrt David Laight
2013-06-07 12:14 ` fsqrt Benjamin Herrenschmidt
2013-06-07 19:19 ` fsqrt Kumar Gala
2013-06-07 23:23 ` fsqrt Benjamin Herrenschmidt
2013-06-07 23:25 ` fsqrt Benjamin Herrenschmidt
2013-06-07 23:30 ` fsqrt Benjamin Herrenschmidt
2013-06-08 0:20 ` fsqrt Dan Malek
2013-06-08 0:34 ` fsqrt Benjamin Herrenschmidt
2013-06-08 1:13 ` fsqrt Dan Malek
2013-06-08 4:31 ` Benjamin Herrenschmidt [this message]
2013-06-09 6:32 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:46 ` fsqrt tiejun.chen
2013-06-07 8:53 ` fsqrt Benjamin Herrenschmidt
2013-06-07 9:02 ` fsqrt tiejun.chen
2013-06-07 12:07 ` fsqrt Benjamin Herrenschmidt
2013-06-07 7:05 ` FSL 64-bit DMA window question Benjamin Herrenschmidt
2013-06-07 7:58 ` Zang Roy-R61911
2013-06-07 8:55 ` Benjamin Herrenschmidt
2013-06-07 9:44 ` Zang Roy-R61911
2013-06-07 12:09 ` Benjamin Herrenschmidt
[not found] ` <1370642488.6813.15@snotra>
2013-06-07 22:02 ` Scott Wood
2013-06-07 22:09 ` Benjamin Herrenschmidt
2013-06-07 22:34 ` Scott Wood
2013-06-07 22:39 ` Benjamin Herrenschmidt
2013-06-07 23:29 ` Scott Wood
2013-06-07 23:33 ` Benjamin Herrenschmidt
2013-06-07 12:09 ` SATA FSL and upstreaming Timur Tabi
2013-05-16 6:17 ` Zang Roy-R61911
2013-05-16 6:23 ` Benjamin Herrenschmidt
2013-05-16 6:33 ` Bhushan Bharat-R65777
2013-05-16 6:34 ` Benjamin Herrenschmidt
2013-05-16 6:35 ` Zang Roy-R61911
2013-05-16 6:37 ` Benjamin Herrenschmidt
2013-05-16 6:41 ` tiejun.chen
2013-05-16 6:48 ` Zang Roy-R61911
2013-05-16 6:24 ` Xie Shaohui-B21989
2013-05-16 6:31 ` Benjamin Herrenschmidt
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=1370665868.3766.451.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=B21989@freescale.com \
--cc=B32616@freescale.com \
--cc=David.Laight@ACULAB.COM \
--cc=R65777@freescale.com \
--cc=afleming@freescale.com \
--cc=d6malek@digitaldans.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=r61911@freescale.com \
--cc=tiejun.chen@windriver.com \
--cc=timur@tabi.org \
/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).