On 07/22/2013 09:36:05 AM, Kumar Gala wrote:
On Jul 16, 2013, at 6:57 AM, Kevin Hao wrote:
> 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
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
the
> hardware FPU and only need some special floating point instructions
to
> be emulated.
>
> Signed-off-by: Kevin Hao <haoke...@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(-)
why make the split, what harm is there in just turning on the full
emulation code to handle the unimplemented cases?
My main motivation in requesting it was to contain the increase in
build time -- math-emu always stuck out to me as something that took a
noticeable amount of time to build. It also reduces the increase in
kernel image size.
who says what some other implementation doesn't need something that
you have in CONFIG_MATH_EMULATION_FULL?
The point is to include any instructions that are known to be missing
in any chip's FPU (excluding chips that don't have an FPU at all). If
it is discovered that some chip is missing an instruction that we
didn't account for, then we'd move that instruction from one list to
the other.
Is the kernel code size really an issue?
It can be when you're storing it on flash -- especially when the growth
is out of control because of the need to justify pruning low-hanging
fruit such as this.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
