They all seem to be directly manipulating the exponent field of a float to make/access lookup tables for every possible exponent. Is this necessary now that everybody has floating-point units built-in to their processors? I can see that it would be a big speed enhancer in a 386 or 68000 but the fpu probably already has internal tables along the same lines.
Martin
Hans-Christoph Steiner wrote:
So it seems that this bug in d_math.c is triggered by turning on the Apple-recommended optimization flags:
http://sourceforge.net/tracker/index.php? func=detail&aid=1692649&group_id=55736&atid=478070
I did notice that there are these warnings in the source. IIRC, optimization generally requires strict aliasing, so it seems that these warnings are probably related to the above bug:
d_math.c: In function 'init_rsqrt': d_math.c:79: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_rsqrt': d_math.c:93: warning: dereferencing type-punned pointer will break strict-aliasing rules d_math.c: In function 'q8_sqrt': d_math.c:101: warning: dereferencing type-punned pointer will break strict-aliasing rules
Here are the lines in question:
79: *(long *)(&f) = l; 93: long l = *(long *)(&f); 101: long l = *(long *)(&f);
Can anyone speak to what's this for and what it can be replaced with so as to follow "strict-aliasing rules". Maybe we could use something like this instead (from http://www.cs.tut.fi/~jkorpela/ round.html ):
#define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\ error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
This requires that you have #include <limits.h> and that you have an error handling routine called error which is a function of type long.
.hc
kill your television
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev