gcc 11.1.0: printf("%.43f\n", 0x1.52f8a8e32e982p-140): printed value is incorrectly rounded
Fri Nov 5 02:54:54 GMT 2021
Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:
> I believe the implementation uses tables: that could be an issue in the
> embedded world; can you comment on the table space required for 32, 64,
> 128 bits?
I don't have a long double implementation of the ryu code; 128 bit
doubles would require 256 bit arithmetic (add/mul, fortunately no
divide), and a bunch of analysis to generate the table values. The
sample code on github only provides 32- and 64- bit
implementations. Picolibc currently has an imprecise printf
implementation for long double that works for Intel (80 bit) Risc-V
(IEEE 128 bit) and Power PC ('double double' 128-bit).
The total size of printf using the Ryu code is substantially smaller
than that required by the current newlib bits as it doesn't drag in the
arbitrary precision functions. The tables are 830 bytes.
I did a presentation in September at the Embedded Linux Conference where
I showed some complete binary numbers that involved printf
On Cortex M3 hardware (an STM32L152 discovery board):
Picolibc 64-bit 6872 24
Picolibc 32-bit 5360 24
Newlib 64-bit 15584 1200+1084
The newlib number for RAM includes both static and sbrk amounts;
picolibc doesn't call sbrk for this example. These are complete
examples, including semihosting code to display the numbers using
openocd on the target hardware.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Newlib