On 08/01/2013 14:01, Charles Swiger wrote:
Hi--
On Jan 8, 2013, at 2:16 AM, David Taylor
<[email protected]> wrote:
Thanks, Harlan. I see that a function SQRT() is used, and that this function
is defined as sqrt() in ntp.h:
#define SQRT(x) (sqrt(x))
I recall seeing /something/ about hardware and software floating point support
in the Raspberry Pi, that some hardware/firmware/software had it and some not.
AFAIK, all of the Raspberry Pis are using an ARM1176JZF-S CPU. The J means
Jazelle (aka ThumbEE); dunno about the Z; the F means H/W floating point (aka
VFP); S means the TrustZone Security Extensions:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html
I wonder whether that might be the cause? I can't imagine sqrt() being broken,
but maybe for very small numbers it's wrongly returning zero? Single precision
versus double precision? As you know, I'm well out of my depth on this, but
could there be a configuration flag to use software FP rather than hardware? I
wonder how best to go about solving this problem?
Well, there are software floating point and H/W testing software available
which one might use to check:
http://www.jhauser.us/arithmetic/TestFloat.html
http://www.netlib.org/fp/ (see UCBTEST)
Regards,
Thanks for that, Charles. Maybe one day I will have the knowledge to
follow that up.
--
Cheers,
David
Web: http://www.satsignal.eu
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
