On Tue, Jan 8, 2013 at 6:01 AM, Charles Swiger <cswi...@mac.com> wrote: > Hi-- > > On Jan 8, 2013, at 2:16 AM, David Taylor > <david-tay...@blueyonder.co.uk.invalid> 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)
i've spent the last two days trying to get the UCBTEST to compile on the RPi with no luck. there are some defines the ieee.c file wants that I just don't grok. As far as TestFloat it requires SoftFloat which has fallen off the interwebs. If you have another test you would like me to try let me know. > > Regards, > -- > -Chuck > > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions james _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
