Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Marcus D. Leech]

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
address@hidden

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.