From: Scott Wood <scottwood@freescale•com>
To: Kumar Gala <galak@kernel•crashing.org>
Cc: Kevin Hao <haokexin@gmail•com>, linuxppc <linuxppc-dev@lists•ozlabs.org>
Subject: Re: [PATCH 1/2] powerpc: split the math emulation into two parts
Date: Mon, 22 Jul 2013 12:25:32 -0500 [thread overview]
Message-ID: <1374513932.15592.5@snotra> (raw)
In-Reply-To: <4E35EEC3-D4D8-4C03-B22E-5574584539AE@kernel.crashing.org> (from galak@kernel.crashing.org on Mon Jul 22 09:36:05 2013)
On 07/22/2013 09:36:05 AM, Kumar Gala wrote:
>=20
> On Jul 16, 2013, at 6:57 AM, Kevin Hao wrote:
>=20
> > For some SoC (such as the FSL BookE) even though there does have
> > a hardware FPU, but not all floating point instructions are
> > implemented. Unfortunately some versions of gcc do use these
> > unimplemented instructions. Then we have to enable the math =20
> emulation
> > to workaround this issue. It seems a little redundant to have the
> > support to emulate all the floating point instructions in this case.
> > So split the math emulation into two parts. One is for the SoC which
> > doesn't have FPU at all and the other for the SoC which does have =20
> the
> > hardware FPU and only need some special floating point instructions =20
> to
> > be emulated.
> >
> > Signed-off-by: Kevin Hao <haokexin@gmail•com>
> > ---
> > arch/powerpc/Kconfig | 20 ++++++++++++++++++++
> > arch/powerpc/math-emu/Makefile | 24 ++++++++++++------------
> > arch/powerpc/math-emu/math.c | 20 ++++++++++++++------
> > 3 files changed, 46 insertions(+), 18 deletions(-)
>=20
> why make the split, what harm is there in just turning on the full =20
> emulation code to handle the unimplemented cases?
My main motivation in requesting it was to contain the increase in =20
build time -- math-emu always stuck out to me as something that took a =20
noticeable amount of time to build. It also reduces the increase in =20
kernel image size.
> who says what some other implementation doesn't need something that =20
> you have in CONFIG_MATH_EMULATION_FULL?
The point is to include any instructions that are known to be missing =20
in any chip's FPU (excluding chips that don't have an FPU at all). If =20
it is discovered that some chip is missing an instruction that we =20
didn't account for, then we'd move that instruction from one list to =20
the other.
> Is the kernel code size really an issue?
It can be when you're storing it on flash -- especially when the growth =20
is out of control because of the need to justify pruning low-hanging =20
fruit such as this.
-Scott=
next prev parent reply other threads:[~2013-07-22 17:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 11:57 [PATCH 0/2] powerpc: split the match emulation into two parts Kevin Hao
2013-07-16 11:57 ` [PATCH 1/2] powerpc: split the math " Kevin Hao
2013-07-22 14:36 ` Kumar Gala
2013-07-22 17:25 ` Scott Wood [this message]
2013-07-16 11:57 ` [PATCH 2/2] powerpc/mpc85xx: only emulate the unimplemented FP instructions on corenet64 Kevin Hao
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=1374513932.15592.5@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=galak@kernel$(echo .)crashing.org \
--cc=haokexin@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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