On Thu, 2012-10-25 at 14:04 +0200, Peter Meerwald wrote: > Hello, > > > > > I was poking around this a bit. An input of 0x3f4aaa95 after the > > > > multiplication with 32767.0 should result in 0x46caa8ff but tuns out to > > > > be 0x46caa900. Still trying to figure out why. > > > > > > I cannot follow your example, it always results in 0x46caa900 (using NEON > > > or not) > > > (gdb) call *(float*)$3 = *(float*)$1 * *(float*)$2 > > $6 = 25940.498 > > (gdb) p /x *(int*)$3 > > $7 = 0x46caa8ff > > This happens on both x86 and the Pandaboard. > > I am curious what the correct result is for that multiplication; > the GDB result is different from actual C code bc suggests that it is: 0.7916653752326965 * 32767.0 = 25940.4993502497662155 > looking at gdb's valarith.c function scalar_binop(), it appears gdb > performs multiplications (BINOP_MUL) as double values -- not entirely > sure, but I wouldn't trust gdb to produce 'accurate' results Yup, my analysis was incorrect. The C code shows it turn up as 25940.5, which your code rounds to 25941, whereas the lrint() in the C code rounds it to 25940. The behaviour of lrint() looks odd to me, but it's consistent on x86 and ARM. Not sure why it is so though (even lrint(0.5) == 0). > > Possibly we're talking about different things here -- I'm referring to > > the float -> s16le conversion. > > I've never seen deviation between NEON and C code for float -> s16le > my claim for one-off was for s16le -> float only You should be able to see it with the code at: http://cgit.collabora.com/git/user/arun/pulseaudio.git/log/?h=neon-wip -- Arun
