l_fp access macros (was: DCF77 driver seems to be broken)

Achim Gratz Stromeko at nexgo.de
Wed Feb 22 18:21:26 UTC 2017


Just out of curiosity, why have you defined the l_fp access macros in
such an overly redundant manner?  I realize that the compiler will
optimize most of that away, but it seems odd to do that in the first
place unless you're expecting to support a platform that has a
non-conforming compiler that doesn't implement conversions between types
of different rank correctly.  Your reliance on C99 and standard types in
other places seems to preclude that.  So how about:

#define lfpfrac(n)              ((uint32_t)(n))
#define lfpsint(n)              ((int32_t)((n) >> 32))
#define lfpuint(n)              ((uint32_t)((n) >> 32))
#define bumplfpsint(n, i)       ((n) += ((int64_t)(i) << 32))
#define bumplfpuint(n, i)       ((n) += ((uint64_t)(i) << 32))

I'm sitting on the fence with the last two (there actually would not
need to be two forms either as the result is the same either way).
There could be processors where the compiler infers a multiply-add in
the explicit multiplication and not recognize the shift-add form.  But
there's no real need for the "BUMP" constant otherwise and a compiler on
a processor that supports halfword access should have no trouble just
loading the upper word directly and not do a shift at all.  Another
argument against using a multiply is that a number of processors have
32x32 multiplication in hardware, but not 64x32 or 64x64.  Even the HIGH
and LOW masking could be replaced by nested casts:

#define setlfpfrac(n, v)        ((n) = (uint64_t)((((uint64_t)(lfpuint(n)))<< 32) | lfpfrac(v)))
#define setlfpsint(n, v)        ((n) = (int64_t)((((int64_t)(v)) << 32) | lfpfrac(n)))
#define setlfpuint(n, v)        ((n) = (uint64_t)((((uint64_t)(v)) << 32) | lfpfrac(n)))

The comment about the signed and unsigned version producing the same
result applies again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves



More information about the devel mailing list