diff options
| author | Dan Gohman <sunfish@mozilla.com> | 2015-09-14 13:14:53 -0700 |
|---|---|---|
| committer | Dan Gohman <sunfish@mozilla.com> | 2015-10-15 08:22:07 -0700 |
| commit | 119d5b3125cd7e20d4ec43c069b234ae0ae9b0b9 (patch) | |
| tree | 38afe0b1c20beae18b418d37c21be881754893c3 /BinaryEncoding.md | |
| parent | 0af5fb141fd794b63faac14d45371b2ea137d8c5 (diff) | |
| download | nanowasm-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
