x87 floating point

[sunfishcode]

With Intel's Quark architecture reportedly lacking SSE units, there is a possibility that an x87-based implementation of WebAssembly may be needed. This is complicated by the fact that x87 has no convenient way to deliver correctly-rounded double-precision floating point results in all cases. Both the Precision Control field, and the 64-bit store instruction, deliver results rounded differently than they would be in a straight 64-bit computation.

(For those following along, I have a plan here, so don't panic.)

[sunfishcode]

This issue is still active; I have a possible solution that I'm still pursuing.

In related news, it appears that OCaml is using x87 arithmetic on some platforms, and this affects ml-proto; see WebAssembly/spec#124 .

[jfbastien]

One obvious solution is to stick with IEEE-754, and call Quark slightly-invalid implementations of WebAssembly. I know your plan makes x87 standard compliant (though dark magic), but I think this is a clever implementation footnote more than anything :-)

[sunfishcode]

Portability will be weakened if implementations ignore testsuite failures.

[jfbastien]

Indeed, but it's always been our stance that some implementations won't be quite compliant and we're OK with this. In this case you have a tentative fix, so it's not really an issue IIUC? Or do you think it may not work out, and you'd like to weaken the IEEE-754 requirement?

[titzer]

IIRC, then the only implementation we were going to allow to be incorrect
was the JS/asm.js polyfill, and in some sense we weren't going to even
claim it was a valid implementation.

On Fri, Oct 23, 2015 at 12:19 PM, JF Bastien [email protected]
wrote:

Indeed, but it's always been our stance that some implementations won't be
quite compliant and we're OK with this. In this case you have a tentative
fix, so it's not really an issue IIUC? Or do you think it may not work out,
and you'd like to weaken the IEEE-754 requirement?

—
Reply to this email directly or view it on GitHub
#303 (comment).

[sunfishcode]

Concerning the rounding issue mentioned above, the following describes a technique to emit extra code to fix up x87 result values to emulate the desired rounding, for example as described here for the sqrt operation:
https://sourceware.org/bugzilla/show_bug.cgi?id=14032
and note that the link to the code in that page is broken; an updated link is here:
http://git.musl-libc.org/cgit/musl/tree/src/math/i386/sqrt.s

Similar sequences could be developed for the other arithmetic operators that need them.

Another issue with x87 is that plain load+store are not bit-preserving in all cases. For example, 0x7fa00000 is converted to 0x7fe0000. To implement wasm with x87, one would need to ensure that all floating-point loads and stores that are not used in conjunction with computations that perform canonicalization be implemented as integer loads and stores.

All three of these issues, double rounding, double-precision mode with expanded exponent range, and load/store NaN canonicalization, are detected by the testsuite. x87-based implementations will not be conforming without the techniques I just described.

I'm not currently planning to do further work on this topic, but people are welcome to reopen this or file a new issue if they have any questions or concerns.

[sunfishcode]

In case anyone's interested, the following paper by Roger Golliver (October 1998), "Efficiently producing default orthogonal IEEE double results using extended IEEE hardware", has some algorithms for performing strict double precision using an x87 unit:

http://www.open-std.org/JTC1/SC22/JSG/docs/m3/docs/jsgn326.pdf