On Thu, 12 Feb 2026, Steve Summit wrote: > Joseph Myers wrote: > > On Wed, 3 Dec 2025, Jakub Jelinek via Gcc wrote: > >> The basic DFP support is in libgcc (again, for many years), but > >> intentionally only in libgcc.a and not in libgcc_s.so.1, because it would > >> quadruple the size of .text section of that library and add further > >> more than 2MB in .rodata (current library has < 3KB .rodata) > > > > There is definitely a speed/space trade-off in how much data you use for > > conversions between binary and decimal FP (the thing that takes a huge > > amount of data in libbid, I think) - you could store less precomputed data > > at the expense of needing to do more multiplications at runtime as part of > > the conversion. > > For those interested -- and I accept that the number may be zero :-) -- > I've been experimenting with an alternate technique for binary/decimal > conversion. I think it will deliver good accuracy and adequate > performance, with far less of a data footprint. (Of course, the > validity of this statement will depend on your definition of > "adequate performance".)
"good accuracy" should mean correctly rounded for all inputs (including the correct quantum exponent for the result, for binary-to-decimal conversion); those operations are defined in IEEE 754 as correctly rounded (which libdfp and the DPD operations in libgcc don't in general achieve). -- Joseph S. Myers [email protected]
