I am under the impression that the compiler has generated code that effectively ignores results in the chirp function.


Version:
Windows optimized S@H Enhanced application by Alex Kan
Version info: SSSE3x (Intel, Core 2-optimized v8-nographics) V5.13 by Alex Kan
SSSE3x Win32 Build 41 , Ported by : Jason G, Raistmer, JDWhale

I use the 'pe explorer/disassembler' and Intel VTune to analyze the assembly source. VTune names this routine 'v_vChirpData'.

When disassembled, the function at 401b0c has a section where the following instruction sequence is used.

At address: 401c77
                movaps  xmm0,xmm4
                addpd   xmm0,xmm3
                subpd   xmm0,xmm4
                subpd   xmm3,xmm0

In this sequence, xmm3 is always zero.

Based on a similar sequence, several other registers are eventually zeroed as well. This undermines the logic in the entire routine.

Could you please verify this against the source code ?

nanobyte.

This is the intended behavior.

Your observation would be true if all floating-point operations were carried out with infinite precision. However, since each operation rounds off to a fixed precision, addition and subtraction are not actually associative. Despite its outward appearances, that instruction sequence does not set xmm3 to zero—it actually generates the fractional part of the value originally contained in xmm3. Specifically, the first three instructions round xmm3 to the nearest integer value using magic numbers (chosen to push all the fractional bits off the end of the mantissa), then place the rounded value into xmm0. Subtracting xmm0 from xmm3 yields the fractional part.

Overzealous compiler optimization based on arithmetic associativity breaks techniques relying on floating-point rounding behavior, like Kahan summation and the code above. Fortunately, the Intel compiler has not done anything of the sort here.