Re: Proposal to switch powerpc64le to IEEE-754 binary128
Javi Hotmail <[email protected]> Tue, 02 Jun 2026 23:56:13 +0000
| Newsgroups | gmane.os.freebsd.devel.ppc |
|---|---|
| Message-ID | <AM0P195MB0722C4E77A8C2F3CA21D3D46AC122@AM0P195MB0722.EURP195.PROD.OUTLOOK.COM> |
------1QAZT0STTFIYSAZSAJQ9WBM7Q0108K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Why do you say "at least on powerpc64le"? Is there a problem of using 128 b= its long double on powerpc64 big endian?=2E On June 2, 2026 7:16:43 PM UTC, Piotr Kubaj <pkubaj@FreeBSD=2Eorg> wrote: >Hello, > >as you may know, FreeBSD currently uses 64-bit long double=2E Since plain >double is also 64-bit, long double actually gives no advantage over >double and is actually the same type=2E > >However, we can do better, at least on powerpc64le=2E On Linux with glibc= , >many distros have already switched to IEEE-754 binary128, which is >128-bit long double=2E On FreeBSD, aarch64 and riscv64 already use 128-bi= t >long double=2E >Apart from the arguments "others do it", 128-bit long double provides >obviously better precision - it's analogous to float vs double=2E >Operations on long doubles are also slower and variables take twice as >much memory, but that's expected of bigger types=2E > >Upgrades are another issue: LLVM uses different functions for operations >on 64-bit long doubles and on binary128=2E This means that after upgrades= , >software using long doubles will need to be rebuilt=2E Otherwise, there's >a risk of strange issues=2E I have verified that bootstraps for all the >major languages work fine (rust, ghc, sbcl, openjdk), but I assume that >some scientific software may have issues=2E > >The current patchset is at: https://reviews=2Efreebsd=2Eorg/D57388 > >Some ports will probably also need to be patched, but that's another >issue=2E > >If you have some spare system for testing, I recommend a try and a >report, straight "make buildworld installworld" is expected to work=2E > >I have a powerpc64le VM where it works: >root@ieeeldbl:~ # echo | cc -dM -E - | grep LDBL >#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__ >#define __LDBL_DECIMAL_DIG__ 36 >#define __LDBL_DENORM_MIN__ 6=2E47517511943802511092443895822764655e-4966= L >#define __LDBL_DIG__ 33 >#define __LDBL_EPSILON__ 1=2E92592994438723585305597794258492732e-34L >#define __LDBL_HAS_DENORM__ 1 >#define __LDBL_HAS_INFINITY__ 1 >#define __LDBL_HAS_QUIET_NAN__ 1 >#define __LDBL_MANT_DIG__ 113 >#define __LDBL_MAX_10_EXP__ 4932 >#define __LDBL_MAX_EXP__ 16384 >#define __LDBL_MAX__ 1=2E18973149535723176508575932662800702e+4932L >#define __LDBL_MIN_10_EXP__ (-4931) >#define __LDBL_MIN_EXP__ (-16381) >#define __LDBL_MIN__ 3=2E36210314311209350626267781732175260e-4932L >#define __LDBL_NORM_MAX__ 1=2E18973149535723176508575932662800702e+4932L > >On a system with the current default, 64-bit long double, the following >will be reported: >root@blackbird:~ # echo | cc -dM -E - | grep LDBL >#define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__ >#define __LDBL_DECIMAL_DIG__ 17 >#define __LDBL_DENORM_MIN__ 4=2E9406564584124654e-324L >#define __LDBL_DIG__ 15 >#define __LDBL_EPSILON__ 2=2E2204460492503131e-16L >#define __LDBL_HAS_DENORM__ 1 >#define __LDBL_HAS_INFINITY__ 1 >#define __LDBL_HAS_QUIET_NAN__ 1 >#define __LDBL_MANT_DIG__ 53 >#define __LDBL_MAX_10_EXP__ 308 >#define __LDBL_MAX_EXP__ 1024 >#define __LDBL_MAX__ 1=2E7976931348623157e+308L >#define __LDBL_MIN_10_EXP__ (-307) >#define __LDBL_MIN_EXP__ (-1021) >#define __LDBL_MIN__ 2=2E2250738585072014e-308L >#define __LDBL_NORM_MAX__ 1=2E7976931348623157e+308L ------1QAZT0STTFIYSAZSAJQ9WBM7Q0108K Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"></= head><body><div dir=3D"auto">Why do you say "at least on powerpc64le&q= uot;? Is there a problem of using 128 bits long double on powerpc64 big end= ian?.<br></div><br><br><div class=3D"gmail_quote"><div dir=3D"auto">On June= 2, 2026 7:16:43 PM UTC, Piotr Kubaj <[email protected]> wrote:</div= ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; bord= er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre class=3D"net-thunderbird-android__plain-text-message-pre"><div dir=3D"= auto">Hello,<br><br>as you may know, FreeBSD currently uses 64-bit long dou= ble. Since plain<br>double is also 64-bit, long double actually gives no ad= vantage over<br>double and is actually the same type.<br><br>However, we ca= n do better, at least on powerpc64le. On Linux with glibc,<br>many distros = have already switched to IEEE-754 binary128, which is<br>128-bit long doubl= e. On FreeBSD, aarch64 and riscv64 already use 128-bit<br>long double.<br>A= part from the arguments "others do it", 128-bit long double provi= des<br>obviously better precision - it's analogous to float vs double.<br>O= perations on long doubles are also slower and variables take twice as<br>mu= ch memory, but that's expected of bigger types.<br><br>Upgrades are another= issue: LLVM uses different functions for operations<br>on 64-bit long doub= les and on binary128. This means that after upgrades,<br>software using lon= g doubles will need to be rebuilt. Otherwise, there's<br>a risk of strange = issues. I have verified that bootstraps for all the<br>major languages work= fine (rust, ghc, sbcl, openjdk), but I assume that<br>some scientific soft= ware may have issues.<br><br>The current patchset is at: <a href=3D"https:/= /reviews.freebsd.org/D57388">https://reviews.freebsd.org/D57388</a><br><br>= Some ports will probably also need to be patched, but that's another<br>iss= ue.<br><br>If you have some spare system for testing, I recommend a try and= a<br>report, straight "make buildworld installworld" is expected= to work.<br><br>I have a powerpc64le VM where it works:<br>root@ieeeldbl:~= # echo | cc -dM -E - | grep LDBL<br>#define __DECIMAL_DIG__ __LDBL_DECIMAL= _DIG__<br>#define __LDBL_DECIMAL_DIG__ 36<br>#define __LDBL_DENORM_MIN__ 6.= 47517511943802511092443895822764655e-4966L<br>#define __LDBL_DIG__ 33<br>#d= efine __LDBL_EPSILON__ 1.92592994438723585305597794258492732e-34L<br>#defin= e __LDBL_HAS_DENORM__ 1<br>#define __LDBL_HAS_INFINITY__ 1<br>#define __LDB= L_HAS_QUIET_NAN__ 1<br>#define __LDBL_MANT_DIG__ 113<br>#define __LDBL_MAX_= 10_EXP__ 4932<br>#define __LDBL_MAX_EXP__ 16384<br>#define __LDBL_MAX__ 1.1= 8973149535723176508575932662800702e+4932L<br>#define __LDBL_MIN_10_EXP__ (-= 4931)<br>#define __LDBL_MIN_EXP__ (-16381)<br>#define __LDBL_MIN__ 3.362103= 14311209350626267781732175260e-4932L<br>#define __LDBL_NORM_MAX__ 1.1897314= 9535723176508575932662800702e+4932L<br><br>On a system with the current def= ault, 64-bit long double, the following<br>will be reported:<br>root@blackb= ird:~ # echo | cc -dM -E - | grep LDBL<br>#define __DECIMAL_DIG__ __LDBL_DE= CIMAL_DIG__<br>#define __LDBL_DECIMAL_DIG__ 17<br>#define __LDBL_DENORM_MIN= __ 4.9406564584124654e-324L<br>#define __LDBL_DIG__ 15<br>#define __LDBL_EP= SILON__ 2.2204460492503131e-16L<br>#define __LDBL_HAS_DENORM__ 1<br>#define= __LDBL_HAS_INFINITY__ 1<br>#define __LDBL_HAS_QUIET_NAN__ 1<br>#define __L= DBL_MANT_DIG__ 53<br>#define __LDBL_MAX_10_EXP__ 308<br>#define __LDBL_MAX_= EXP__ 1024<br>#define __LDBL_MAX__ 1.7976931348623157e+308L<br>#define __LD= BL_MIN_10_EXP__ (-307)<br>#define __LDBL_MIN_EXP__ (-1021)<br>#define __LDB= L_MIN__ 2.2250738585072014e-308L<br>#define __LDBL_NORM_MAX__ 1.79769313486= 23157e+308L<br></div></pre></blockquote></div></body></html>= ------1QAZT0STTFIYSAZSAJQ9WBM7Q0108K--