From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: libm accuracy, eglibc compared to glibc -- solved
Date: Fri, 21 Mar 2014 11:45:10 -0500 [thread overview]
Message-ID: <532C6C96.7020901@windriver.com> (raw)
In-Reply-To: <ED3E0BCACD909541BA94A34C4A164D4C5B3A4C94@post.tritech.se>
On 3/21/14, 7:10 AM, Mats Kärrman wrote:
> Hi,
>
> On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
>> My "home made" hard float tune for PowerPC looks like this:
>>
>> ------------------------------------------------------------------
>> # Tune for the e300c3 core
>> require conf/machine/include/tune-ppce300c3.inc
>>
>> # Use hardware floating point
>> AVAILTUNES += "ppce300c3hf"
>> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
>> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
>> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf"
>> DEFAULTTUNE = "ppce300c3hf"
>> ------------------------------------------------------------------
>>
>
> I found the reason for the error (deviance) in the sqrt function. glibc has
> special code for PowerPC 603e core (e300 is an optimized variant of 603e).
> By adding the following line to the tuning I now get the same result as
> for all other environments that I've tried:
>
> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", "-with-cpu=603e", "", d)}"
>
> Does anyone know about the reason for having soft-float as the default and
> only available alternative for e300c2/3 tunings?
My guess is because e300 e300c2 were both soft-float designs. And e300c3 is the
first hard float design.
The e300c3 should inherit and use the 603e directly. This includes definiting
the TUNE_FEATURES that the 603e does. If it doesn't do that, I'd suggest it's a
mistake.
The default 603e tune should include:
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e",
"-with-cpu=603e", "", d)}"
or similar already -- and should already be hard float enabled. (ppc603e
soft-float should be the alternative -- as it is significantly rarer and the
deviation.)
> Would it be worthwhile to send a patch to add the hf tuning to OE-core?
As the e300c3 should be hard float, we shouldn't have the 'hf' designation.
Otherwise, we should ensure the e300c3 tune is correctly configured.
> In that case what tests should be performed before that and what (related)
> tests are performed by the OE auto-builder?
>
> BR // Mats
>
next prev parent reply other threads:[~2014-03-21 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 12:10 libm accuracy, eglibc compared to glibc -- solved Mats Kärrman
2014-03-21 16:45 ` Mark Hatle [this message]
2014-03-21 17:06 ` Khem Raj
2014-03-27 15:16 ` Mats Kärrman
2014-03-27 16:00 ` Khem Raj
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=532C6C96.7020901@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.