From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18940 invoked from network); 29 Jun 2020 20:46:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2020 20:46:19 -0000 Received: (qmail 17763 invoked by uid 550); 29 Jun 2020 20:46:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17745 invoked from network); 29 Jun 2020 20:46:15 -0000 From: Pascal Cuoq To: "musl@lists.openwall.com" Thread-Topic: [musl] Posits support under Musl libc? Thread-Index: AQHWThS2FFiyV7wzsEe2VODid21MI6jwCLQx Date: Mon, 29 Jun 2020 20:46:02 +0000 Message-ID: <1593463562766.15318@trust-in-soft.com> References: <32b4-5ef9e500-33-6d961680@199533904> In-Reply-To: <32b4-5ef9e500-33-6d961680@199533904> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [91.172.139.202] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [musl] Posits support under Musl libc? =0A= > Posits are lightweight, fast=0A= =0A= Ah, this is a difference in the interpretation of words. I meant lightweigh= t in the sense that you can add two numbers in one instruction without link= ing with and calling additional emulation code, and fast in the sense that = you can do from one to four additions per cycle depending on what else you = have to do at the same time. [1]=0A= =0A= > and produce the same reasults across platforms, something which IEEE 754 = doesn't guarantee. To top that, IEEE 754 isn't even a standard but just a s= et of guidelines which are usually implemented incorrectly due to misinterp= retation or lack of expertise. So in that sense, Posits are safer than Floa= ting-point.=0A= =0A= This is a remarkable exaggeration. The actual differences of interpretation= between IEEE 754 implementations are extremely minor for basic operations = (it would be inappropriate to start discussing them considering the current= level of discourse). On the other hand, there are differences between plat= forms in the implementations of trigonometric and other math functions. Thi= s was a well-weighted decision by the IEEE 754 standardization committee, i= n order not to stifle research into better implementations for these functi= ons. Surely you are not referring to such differences? Because I do not see= how posits fix these (apart from having no implementations for math functi= ons).=0A= =0A= If you bother to investigate where differences in floating-point computatio= ns come from, as David Monniaux did [2], you end up with the conclusion tha= t all the inconsistencies come from:=0A= =0A= A- hardware-design decisions make in the 1980s when it was not interesting = to implement more than one format, so that several FPU implemented the (wid= est feasible) 80-bit double-extended format and let compilers generate code= that emulated single- and double-precision imperfectly from that. Compiler= s could have done better but the hardware design decisions are partially to= blame. Modern desktop hardware provides single- and double-precision opera= tions, of course, which IEEE 754 was smart enough to standardize before it = was practical to have all three in a single FPU.=0A= =0A= B- compilers who produce code that violate IEEE 754 even when the hardware = offers a perfect implementation of it, e.g. generating the FMA instruction = for code that contains a multiplication and an addition.=0A= =0A= I reluctantly admit that you have a point: all the 0 processors who provide= posit basic operations implement the exact same semantics, and the 0 compi= lers who support posits avoid the troublesome optimizations that plague som= e programming languages.=0A= =0A= Note that Type I unums have been the greatest floating-point format ever in= vented (according to their inventor) for longer than posits have existed, s= o if we did have hardware implementing these ideas, it would be probably 60= % Type I unum implementations, 35% Type II unums, and 5% posits. You would = not actually get the same results across platforms for basic operations. In= 2023, Gustafson will have a better idea yet. Better wait for unums Type IV= .=0A= =0A= [1] https://www.agner.org/optimize/instruction_tables.pdf=0A= [2] https://hal.archives-ouvertes.fr/hal-00128124v5=0A=