Re: Proposal to switch powerpc64le to IEEE-754 binary128

--OMY8KCKeIqwo1OsO
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?.
>=20
>=20
> On June 2, 2026 7:16:43 PM UTC, Piotr Kubaj <[email protected]> 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

--OMY8KCKeIqwo1OsO
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEEycyIeNkkgohzsoorelmbhSCDnJ0FAmofuPobFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMCwyAAoJEHpZm4Ugg5ydYrYQALqPGM7pDp4FO+BvwueW
Lc5JnJWgQue1yKM9R+z+gFbUcHLeQFL/kRMrLO+aYNkg3+M1x/RQVitYfXAeezk8
z4OcSWXV6qEfb2VVOeQeBnjeirI6y8g7hRwirufv2ZcdTnh4y+mX0u5zB/Cbl+Cf
yzj7n/v0NOca8fdn7GgO/IpQfwAm2W2+41Kl4wSuWrGcIX/m1/3bOigobKkTGDOK
TYsWJWFqBEEjyGXNyi6Q/5Ydh0S4cM+arP36TDQ4M2g32HcpLgf8rHPhiMlnWIOW
/RBp2BBJ5ohhd/vQi0alJFmGdPlLmW8qnBwd4XNBdILpmuF1tuYmWTVmqKt+iQ2t
e5PSNr3Q/sc6M9rPAIUyDN2/9iDWGy7MKHonQ0l/j2TL9y2+C6uHvbnU8mRVuRuD
rCu9oUTbZ9Z1sK74jZ4BfMXGi13Egp0xoGh8Cor21IahtegVDKuvajfSNsa3N3qb
ZhR7QXLb4aBgM8uyIDqGmiO9jpORRwhvyOQW8XcPup6wDuKuRmV9l1ATghRk/zpg
NaExPgj0cAP6xbMJUa0WSdZgS5eDe4UjPFzpQZ3Rdo4HchRIJ3biqjErZhZewL61
hSt75IxiUNjQULw6FFVoi3hr2oi8GsD104T1efXdat9XrXpsVH7K5LeL3vZPklYC
SmpGzDEtggfiBLxnT/aJx1fn
=PlWz
-----END PGP SIGNATURE-----

--OMY8KCKeIqwo1OsO--