Re: gcc 11.1.0: printf("%.43f\n", 0x1.52f8a8e32e982p-140): printed value is incorrectly rounded

Keith Packard <[email protected]> Thu, 04 Nov 2021 19:54:54 -0700

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

Brian Inglis <[email protected]> writes:

> Keith,
>
> 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

        #include <stdio.h>

        void main(void)
        {
                printf("%g\n", 355.0/113.0);
        }

On Cortex M3 hardware (an STM32L152 discovery board):

                             ROM     RAM
    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.

-- 
-keith

signature.asc (application/pgp-signature, 832 B)