<br><div class="gmail_quote"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
</div>First of all you do know that floating-point (FP) is inherently<br>
imprecise, right?<br>
</blockquote></div><div><br>Oh yes, that's why I wrote the disclaimer about "known problem"... :-)<br><br>Its trivial to write a c program with the exact same behaviour, unless you add e.g. "-mfpmath=sse -msse2" for gcc (as you say, this is enabled by default on x86-64).<br>


 <br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, the problem here is the quirky nature of the old x87 FP unit,<br>
which is what 32-bit x86s use by default in most OS environments.<br>
(I believe MacOSX is one of the few to default to SSE2 even in 32-bit.)<br>
<br>
The x87 computes internally with an 80-bit format different from<br>
standard IEEE 64-bit floats. It does however round the result of<br>
each computation according to the precision control (which defaults<br>
to the 80-bit extended format), and it rounds when storing values<br>
to IEEE 64-bit floats in memory. So the final result is highly<br>
sensitive to the sequence of loads, arithmetics, and stores done<br>
during the computation.<br>
<br>
The BEAM virtual machine will store each intermediate result to<br>
memory, causing rounding to the IEEE 64-bit format.<br>
<br>
HiPE on x86-32/x87 will keep intermediate results in the x87<br>
register file (which technically is a stack) as long as possible.<br>
The benefit is improved performance from avoiding memory accesses.<br>
It also improves accuracy by avoiding some rounding operations.<br>
<br>
And that's the problem. The nature of FP is such that computing<br>
a more accurate result can be considered an error.<br>
<br>
A possible solution might be to program the x87's rounding control<br>
to always round to standard double precision. That should make BEAM<br>
and HiPE produce similar results, but it might break FP library<br>
routines.<br>
<br>
Having HiPE store each intermediate value just for the sake of<br>
BEAM compatibility would be awful.<br>
</blockquote></div><div><br>I fully agree!<br> <br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The real solution is to forget about x87 and go to x86-64/SSE2.<br>
<font color="#888888"></font></blockquote></div><div><br>sse/sse2 support on x86-32 is not an option?<br><br>I am just asking out of curiosity, I already have a workaround so this is not critical for me in any way. I guess money/time is better spent elsewhere if this is a lot of work.<br>


 <br>BR /Fredrik<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
/Mikael<br>
</font></blockquote></div><br>
</div><br>