Date: Wed, 3 Jun 2026 17:37:39 +0900 From: Javi Hotmail <volkovdablo@hotmail.com> To: Piotr Kubaj <pkubaj@FreeBSD.org> Cc: ppc@freebsd.org, freebsd-ppc@FreeBSD.org Subject: Re: Proposal to switch powerpc64le to IEEE-754 binary128 Message-ID: <AM0P195MB0722F85F2BF72B0229F08EF6AC132@AM0P195MB0722.EURP195.PROD.OUTLOOK.COM> In-Reply-To: <ah-4-7NZk9qFoxtL@talos-powerpc64le> References: <ah8sFn_mmGrJp9Ru@talos-powerpc64le> <AM0P195MB0722C4E77A8C2F3CA21D3D46AC122@AM0P195MB0722.EURP195.PROD.OUTLOOK.COM> <ah-4-7NZk9qFoxtL@talos-powerpc64le>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Understood, I didn't read the spec, so I thought that aside from VSX you could do something like using two 64 bits register instead for PPC970/POWER4 and similar old CPUs that do not have VSX. Thanks for the clarification, Javi. On 6/3/26 14:17, Piotr Kubaj wrote: > Depends what you mean. This proposal is about switching to IEEE-754 long > double. It requires VSX, so doing the same on big-endian would raise the > baseline to POWER7. There's no plan for that. > > There is IBM long double, but it's entirely non-standard. It would work > even on G5, but while IEEE-754 long double is definitely an upgrade, IBM > long double is either a downgrade or a sidegrade, so it's better to just > stay on 64-bits for big-endian. > > On 26-06-02 23:56:13, Javi Hotmail wrote: >> Why do you say "at least on powerpc64le"? Is there a problem of using 128 bits long double on powerpc64 big endian?. >> >> >> On June 2, 2026 7:16:43 PM UTC, Piotr Kubaj<pkubaj@FreeBSD.org> wrote: >>> Hello, >>> >>> as you may know, FreeBSD currently uses 64-bit long double. Since plain >>> double is also 64-bit, long double actually gives no advantage over >>> double and is actually the same type. >>> >>> However, we can do better, at least on powerpc64le. On Linux with glibc, >>> many distros have already switched to IEEE-754 binary128, which is >>> 128-bit long double. On FreeBSD, aarch64 and riscv64 already use 128-bit >>> long double. >>> Apart from the arguments "others do it", 128-bit long double provides >>> obviously better precision - it's analogous to float vs double. >>> Operations on long doubles are also slower and variables take twice as >>> much memory, but that's expected of bigger types. >>> >>> Upgrades are another issue: LLVM uses different functions for operations >>> on 64-bit long doubles and on binary128. This means that after upgrades, >>> software using long doubles will need to be rebuilt. Otherwise, there's >>> a risk of strange issues. 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. >>> >>> The current patchset is at:https://reviews.freebsd.org/D57388 >>> >>> Some ports will probably also need to be patched, but that's another >>> issue. >>> >>> If you have some spare system for testing, I recommend a try and a >>> report, straight "make buildworld installworld" is expected to work. >>> >>> 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.47517511943802511092443895822764655e-4966L >>> #define __LDBL_DIG__ 33 >>> #define __LDBL_EPSILON__ 1.92592994438723585305597794258492732e-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.18973149535723176508575932662800702e+4932L >>> #define __LDBL_MIN_10_EXP__ (-4931) >>> #define __LDBL_MIN_EXP__ (-16381) >>> #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L >>> #define __LDBL_NORM_MAX__ 1.18973149535723176508575932662800702e+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.9406564584124654e-324L >>> #define __LDBL_DIG__ 15 >>> #define __LDBL_EPSILON__ 2.2204460492503131e-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.7976931348623157e+308L >>> #define __LDBL_MIN_10_EXP__ (-307) >>> #define __LDBL_MIN_EXP__ (-1021) >>> #define __LDBL_MIN__ 2.2250738585072014e-308L >>> #define __LDBL_NORM_MAX__ 1.7976931348623157e+308L [-- Attachment #2 --] <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <p><font face="Courier New, Courier, monospace">Understood,</font></p> <p><font face="Courier New, Courier, monospace">I didn't read the spec, so I thought that aside from VSX you could do something like using two 64 bits register instead for PPC970/POWER4 and similar old CPUs that do not have VSX.</font></p> <p><font face="Courier New, Courier, monospace">Thanks for the clarification,</font></p> <p><font face="Courier New, Courier, monospace">Javi.</font></p> <div class="moz-cite-prefix">On 6/3/26 14:17, Piotr Kubaj wrote:<br> </div> <blockquote type="cite" cite="mid:ah-4-7NZk9qFoxtL@talos-powerpc64le"> <pre wrap="" class="moz-quote-pre">Depends what you mean. This proposal is about switching to IEEE-754 long double. It requires VSX, so doing the same on big-endian would raise the baseline to POWER7. There's no plan for that. There is IBM long double, but it's entirely non-standard. It would work even on G5, but while IEEE-754 long double is definitely an upgrade, IBM long double is either a downgrade or a sidegrade, so it's better to just stay on 64-bits for big-endian. On 26-06-02 23:56:13, Javi Hotmail wrote: </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">Why do you say "at least on powerpc64le"? Is there a problem of using 128 bits long double on powerpc64 big endian?. On June 2, 2026 7:16:43 PM UTC, Piotr Kubaj <a class="moz-txt-link-rfc2396E" href="mailto:pkubaj@FreeBSD.org"><pkubaj@FreeBSD.org></a> wrote: </pre> <blockquote type="cite"> <pre wrap="" class="moz-quote-pre">Hello, as you may know, FreeBSD currently uses 64-bit long double. Since plain double is also 64-bit, long double actually gives no advantage over double and is actually the same type. However, we can do better, at least on powerpc64le. On Linux with glibc, many distros have already switched to IEEE-754 binary128, which is 128-bit long double. On FreeBSD, aarch64 and riscv64 already use 128-bit long double. Apart from the arguments "others do it", 128-bit long double provides obviously better precision - it's analogous to float vs double. Operations on long doubles are also slower and variables take twice as much memory, but that's expected of bigger types. Upgrades are another issue: LLVM uses different functions for operations on 64-bit long doubles and on binary128. This means that after upgrades, software using long doubles will need to be rebuilt. Otherwise, there's a risk of strange issues. 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. The current patchset is at: <a class="moz-txt-link-freetext" href="https://reviews.freebsd.org/D57388">https://reviews.freebsd.org/D57388</a>; Some ports will probably also need to be patched, but that's another issue. If you have some spare system for testing, I recommend a try and a report, straight "make buildworld installworld" is expected to work. 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.47517511943802511092443895822764655e-4966L #define __LDBL_DIG__ 33 #define __LDBL_EPSILON__ 1.92592994438723585305597794258492732e-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.18973149535723176508575932662800702e+4932L #define __LDBL_MIN_10_EXP__ (-4931) #define __LDBL_MIN_EXP__ (-16381) #define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L #define __LDBL_NORM_MAX__ 1.18973149535723176508575932662800702e+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.9406564584124654e-324L #define __LDBL_DIG__ 15 #define __LDBL_EPSILON__ 2.2204460492503131e-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.7976931348623157e+308L #define __LDBL_MIN_10_EXP__ (-307) #define __LDBL_MIN_EXP__ (-1021) #define __LDBL_MIN__ 2.2250738585072014e-308L #define __LDBL_NORM_MAX__ 1.7976931348623157e+308L </pre> </blockquote> </blockquote> </blockquote> </body> </html>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AM0P195MB0722F85F2BF72B0229F08EF6AC132>