hi miller, hi devs ...
the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ...
static void init_rsqrt(void) { int i; for (i = 0; i < DUMTAB1SIZE; i++) { float f; long l = (i ? (i == DUMTAB1SIZE-1 ? DUMTAB1SIZE-2 : i) : 1)<< 23; *(long *)(&f) = l; rsqrt_exptab[i] = 1./sqrt(f); } for (i = 0; i < DUMTAB2SIZE; i++) { float f = 1 + (1./DUMTAB2SIZE) * i; rsqrt_mantissatab[i] = 1./sqrt(f); } }
couldn't really look into it, but i guess, the wild cast in *(long *)(&f) = l; might be a problem on th x86_64 architecture ...
not really a problem for devel, since devel most likely uses sse instructions to do the rsqrt computation ... but someone who is into vanilla pd might be interested in having a look at it ..
cheers ... tim
Hi all,
the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ...
static void init_rsqrt(void) { int i; for (i = 0; i < DUMTAB1SIZE; i++) { float f; long l = (i ? (i == DUMTAB1SIZE-1 ? DUMTAB1SIZE-2 : i) : 1)<< 23; *(long *)(&f) = l; rsqrt_exptab[i] = 1./sqrt(f); } for (i = 0; i < DUMTAB2SIZE; i++) { float f = 1 + (1./DUMTAB2SIZE) * i; rsqrt_mantissatab[i] = 1./sqrt(f); } }
couldn't really look into it, but i guess, the wild cast in *(long *)(&f) = l; might be a problem on th x86_64 architecture ...
i don't have physical access to a 64-bit machine bit it should be no problem replacing long by int which is 32 bit in any case (i don't think there are any 16 bit platforms left, are they?!), or by some other 32-bit signed integer type, like __int32 under msvc.
best greetings, Thomas
Tim Blechmann wrote:
hi miller, hi devs ...
the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ...
hmm, it seems that my 32bit and my 64bit machines are producing the same results when using [rsqrt~]
so why do you think that it is broken ? do you have a test patch exhibiting wrong behaviour ?
mfg.a.dsr IOhannes
On Sun, 11 Sep 2005, IOhannes m zmoelnig wrote:
Tim Blechmann wrote:
hi miller, hi devs ... the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ...
hmm, it seems that my 32bit and my 64bit machines are producing the same results when using [rsqrt~] so why do you think that it is broken ? do you have a test patch exhibiting wrong behaviour ?
You have to compile pd as 64-bit for the bug to happen.
Because ix86 is little-endian, the result of writing a long in the float variable does the right thing and so it might very well work, depending on how the compiler did the job. however, it's a case of buffer overflow, because 64 bits are written to stack instead of 32 bits, so any other variable on the same stack frame might get clobbered.
In this case, there are three variables in that frame. The two 32 bit variables will most likely be put next to each other for alignment reasons. If the loop counter (i) is just after the float (f) then the loop will run forever because the buffer overflow will cause i to get assigned 0 over and over.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 11 Sep 2005, IOhannes m zmoelnig wrote:
Tim Blechmann wrote:
hi miller, hi devs ... the current implementation of rsqrt~ is most likely broken. i was sshing to carmen's amd64 machine ... looked like that filling the lookup table isn't really working ...
hmm, it seems that my 32bit and my 64bit machines are producing the same results when using [rsqrt~] so why do you think that it is broken ? do you have a test patch exhibiting wrong behaviour ?
You have to compile pd as 64-bit for the bug to happen.
oh i forgot to mention: my 64bit machine is running debian x86_64; all my applications are compiled as 64-bit.
so the bug should expose to me but i still don't even know what it is (apart from "a bug")
mfg.asd.r IOhannes
On Sun, 11 Sep 2005, IOhannes m zmoelnig wrote:
oh i forgot to mention: my 64bit machine is running debian x86_64; all my applications are compiled as 64-bit. so the bug should expose to me but i still don't even know what it is (apart from "a bug")
The rsqrt bug is not guaranteed to manifest itself because memory layout decisions made by the compiler may very well hide the bug, e.g. if the area clobbered by the buffer overflow is left unused.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 11 Sep 2005, IOhannes m zmoelnig wrote:
oh i forgot to mention: my 64bit machine is running debian x86_64; all my applications are compiled as 64-bit. so the bug should expose to me but i still don't even know what it is (apart from "a bug")
The rsqrt bug is not guaranteed to manifest itself because memory layout decisions made by the compiler may very well hide the bug, e.g. if the area clobbered by the buffer overflow is left unused.
so still not knowing what might happen: it seems to be a buffer overflow that crashes pd as soon as the [rsqrt~]-object is created ? (or the dsp is turned on ??)
i'm just interested.
mfg.a.dsr IOhannes
The rsqrt bug is not guaranteed to manifest itself because memory layout decisions made by the compiler may very well hide the bug, e.g. if the area clobbered by the buffer overflow is left unused.
so still not knowing what might happen: it seems to be a buffer overflow that crashes pd as soon as the [rsqrt~]-object is created ? (or the dsp is turned on ??)
pd didn't start up ... interrupting the pd process showed that it's in the process of filling the rsqrt lookup table ...
matju's guess, that the loop counter has been overridden might be a reasonable explanation ... fit's more or less to what i've experienced ...
t
Tim Blechmann schrieb:
The rsqrt bug is not guaranteed to manifest itself because memory layout decisions made by the compiler may very well hide the bug, e.g. if the area clobbered by the buffer overflow is left unused.
so still not knowing what might happen: it seems to be a buffer overflow that crashes pd as soon as the [rsqrt~]-object is created ? (or the dsp is turned on ??)
pd didn't start up ... interrupting the pd process showed that it's in the process of filling the rsqrt lookup table ...
matju's guess, that the loop counter has been overridden might be a reasonable explanation ... fit's more or less to what i've experienced ...
it's pretty obvious that *(long *)(&f) = l; must/can be fatal on a 64 bit platform if f is 32 bits and long is 64 bits, no? Some data neighboring f on the stack must suffer from that.
all the best, Thomas
On Sun, 11 Sep 2005, IOhannes m zmölnig wrote:
so still not knowing what might happen: it seems to be a buffer overflow that crashes pd as soon as the [rsqrt~]-object is created ? (or the dsp is turned on ??) i'm just interested.
What might be happening is that I'm committing the fix to devel_0_39.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hmm, it seems that my 32bit and my 64bit machines are producing the same results when using [rsqrt~]
so why do you think that it is broken ? do you have a test patch exhibiting wrong behaviour ?
i was sshing to carmen's amd64 machine, trying to debug on his machine ...
pd got stuck while filling the table, (at least gdb told me that). if it's working great on machine, maybe it was a different problem ...
cheers .... tim
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann