From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id 648C53858D35 for ; Fri, 5 Nov 2021 02:54:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 648C53858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=keithp.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=keithp.com Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id A18683F31114; Thu, 4 Nov 2021 19:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1636080896; bh=oMsf/5dijUY0TVsCV8g5QpAszdN8I2D9jCQC7tcH//E=; h=From:To:Subject:In-Reply-To:References:Date:From; b=N1E8S9v5fTmhdymW+9JcNl1C/ZCd5kySM1nK9tgEAg2G6oP7F3Fl97C3DFEYIKuAn 4muD0pUHmLlGiPGo+z5VxPgLfV0d+DGFD+HIOlfxgFh3wMQJRn/ItI/IQEjJHFipK/ CRYSFDktA+mTvhjTI+4lLuBSuWSdloYEK7yEHGUCLDojwqmRrpfxAnmLVXISGDdR25 EixyIBW8q02fVVe36u7Fn8wCxUw6Shw169Il9JpW88V+7uxZTvcbwsuIaL3/plh7R8 4f6yLmClk29MxgY1QcPpYN2HmguNYDKA2aV9kwNKlEhaPzvGr4yDZen4KkDobGdYOX lcU7Mu7PCTEDQ== X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ONmkLd3NBbnR; Thu, 4 Nov 2021 19:54:55 -0700 (PDT) Received: from keithp.com (koto.keithp.com [192.168.11.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 135AB3F31112; Thu, 4 Nov 2021 19:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=keithp.com; s=mail; t=1636080895; bh=oMsf/5dijUY0TVsCV8g5QpAszdN8I2D9jCQC7tcH//E=; h=From:To:Subject:In-Reply-To:References:Date:From; b=FqJSxvKcyI2qEJaosKwAIEAkXus1vJxBqfAY+QHMW0S7cUAffmFLFdv9mrMNlxTPt yxm+mMtnpaFJfde18JHpS6n1LQJw2tsHp3IwhitPN4+J59W3fNG3nXT7uYsIsGchfi gVik95/bVUFtA4SyagyWad7JnvzOOTXbnGISc3dx22Gzqrol7JDIbJ00wZeVwovP9w cB89O32Xsr/H0o/QxzL2xROOlZ7AEtsfpEVppyrsisxRjR7NU2mmDtJKV/O1qWn4GY amOHKPMmfrk3007KbpVWgvPJi4DGm8L2uB8eCo9OuvcrDsEQkIMjuYbKNVEwpXXE+9 Gv4w98EdNdahg== Received: by keithp.com (Postfix, from userid 1000) id C40271E6013C; Thu, 4 Nov 2021 19:54:54 -0700 (PDT) From: Keith Packard To: Brian Inglis , newlib@sourceware.org Subject: Re: gcc 11.1.0: printf("%.43f\n", 0x1.52f8a8e32e982p-140): printed value is incorrectly rounded In-Reply-To: <6b742e91-5a56-8a4d-c9a5-b33d2b33bb66@SystematicSw.ab.ca> References: <87ilx7vpco.fsf@keithp.com> <90598863-5b2c-30a1-ddb4-0d6d7421a835@nadler.com> <874k8rvm49.fsf@keithp.com> <6b742e91-5a56-8a4d-c9a5-b33d2b33bb66@SystematicSw.ab.ca> Date: Thu, 04 Nov 2021 19:54:54 -0700 Message-ID: <87r1bvtipt.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 02:54:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian Inglis writes: > Keith, > > I believe the implementation uses tables: that could be an issue in the=20 > embedded world; can you comment on the table space required for 32, 64,=20 > 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 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. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmGEnP4ACgkQ2yIaaQAA ABFZIxAAqm8A9VOCVdXb8H2FZDTbErY938rD7XHfSyWbjzbX/AFwTUxcpycOKDvU jYE37e4sMggLBiMoMJQbEktYR+8A1nwVAS0ryGnZt9bp1LYVt3HeRZfuq/a1hlyh R9zuVegIUUJTu+jgUIIxKDPpF5HOADyve5njToFL3SYooJ5LxTQlv9wF8Vkjlnaq VvRholLfC5an/K6KV2sQP6UDg5QgyEd6FVbqvTYTMAr3XnlIRNEgefWGDDs3TR/p fT4R92Y+k3GAqBWw6On6QMef2GcqpDN1vJoHylcwyEaF5pBs/gxqwhfbsHsVPyWg FCZ2/ZJ1YMeP8+2TXVBNUsuXZaBokx4xXJ1ay5UBh6nFi1wEjawpXVI2GG5uI2Kr UT+eRDCPlg49HNXdlHFIgyQdsaAEqCAxCGO4NOqEa03BVUiORvQhnsJU5IcJrHod c3UWV9JyPE5VzwfKgw6sjzlBpM5uKoO3P1xQ/31GykLtfBQeZhhoTGzwtNfJX1Um AK/SA1TvKr1U9357tp0iMB9aSNGkc8n7L8dXEHvQmHb1A0Nw8WA6nkmEkpfv6WV2 PMJ6hsmh0EnflGxslFpVF3jXlAkXsM+GL9DggUcblvH7wqYLPig1JtKyi8EvRryd FJt72Pex9Z19pdRRpIy8BI3XucqRgP+58661bVaooNjKZj5bNIk= =63pw -----END PGP SIGNATURE----- --=-=-=--