aboutsummaryrefslogtreecommitdiff
path: root/BinaryEncoding.md
diff options
context:
space:
mode:
authorDan Gohman <sunfish@mozilla.com>2015-09-14 13:14:53 -0700
committerDan Gohman <sunfish@mozilla.com>2015-10-15 08:22:07 -0700
commit119d5b3125cd7e20d4ec43c069b234ae0ae9b0b9 (patch)
tree38afe0b1c20beae18b418d37c21be881754893c3 /BinaryEncoding.md
parent0af5fb141fd794b63faac14d45371b2ea137d8c5 (diff)
downloadnanowasm-design-119d5b3125cd7e20d4ec43c069b234ae0ae9b0b9.tar.gz
Describe WebAssembly's C/C++ ABI floating point types.
The rationale for making C/C++ long double something other than 64-bit is: - there are use cases for quad-precision floating point types, and "long double" is a friendlier way to satisfy those use cases than extensions like "__float128" since "long double" has the benefit of libm and printf API support. - long double is a lost cause in terms of portable functionality anyway. 64-bit, 80-bit, and 128-bit long double types are in use in popular platforms, so people who want portable results aren't using it. - it's also a lost cause in terms of portable performance, as it's already significantly slower than double on several widely popular platforms, so people who want portable performance already have motivation to avoid it. The rationale for picking quad-precision over double-double is that even though double-double can be significantly faster, it has surprising numeric properties which make it undesirable to impose on unsuspecting code.
Diffstat (limited to 'BinaryEncoding.md')
0 files changed, 0 insertions, 0 deletions