On 07/30/2013 06:03 PM, Douglas Geiger wrote:
Marcus,
(Forgive my ignoring the context of the parent discussion to answer
your question):
I can tell you that in the case of ARM at least NEON instructions are
is *not* IEEE-754 compliant. One optimization in particular that I can
recall off the top of my head is that denormalized floats are flushed
to zero (i.e. *extremely* small values get interpreted as zeros). I
can't speak to whether this is actually an issue for any given
application, but ARM specifically notes that NEON instructions are not
IEEE compliant, and that therefore users should aware of potential
issues. They also point out other non-compliant bits in their TRM's
(e.g. for the Cortex-A9:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0409e/CIHEJAGA.html). I'll
note that most versions of GCC do not emit NEON instructions for
floating point math unless you pass set -funsafe-math-optimizations
(see
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mfpu-1143).
Of course that statement doesn't apply to hand assembly (or intrinsics).
Doug
--
Doug Geiger
doug.gei...@bioradiation.net <mailto:doug.gei...@bioradiation.net>
Ah, that makes perfect sense.
In the "olden days", various CPUs had various FP implementations, with
subtle differences in things like rounding rules, etc. Then IEEE-754
was published,
and most CPUs began to use IEEE-754 formats and semantics. But
there, I guess exceptions, and this is one case where doing a QA test
that is
looking for bit-of-bit identical patterns would be just wrong.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
