From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 13cafa55 for ; Sat, 18 Jan 2020 09:40:29 +0000 (UTC) Received: (qmail 23983 invoked by uid 550); 18 Jan 2020 09:40:28 -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 23965 invoked from network); 18 Jan 2020 09:40:27 -0000 Date: Sat, 18 Jan 2020 10:40:15 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Message-ID: <20200118094015.GE23985@port70.net> Mail-Followup-To: musl@lists.openwall.com References: <20200116161427.GO30412@brightrain.aerifal.cx> <20200116193343.GP30412@brightrain.aerifal.cx> <20200117164143.GB2020@voyager> <20200118011535.GD23985@port70.net> <20200118053759.GX30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200118053759.GX30412@brightrain.aerifal.cx> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Considering x86-64 fenv.s to C * Rich Felker [2020-01-18 00:37:59 -0500]: > On Sat, Jan 18, 2020 at 04:03:01PM +1100, Damian McGuckin wrote: > > Do we have to start supporting 128-bit floats, we will need to use > > the __int28_t and __uint128_t about which I know nothing. But they > > have their own limitations. > > No, these are not used at all in musl, and are problematic types > because they can't formally be extended integer types, since they > mismatch intmax_t being 64-bit. We just use "ldshape". there is one place where __int128 is used: powerpc64 jmp_buf and i think aarch64 should use it in ucontext, both are places where quad float regs are saved, but the kernel and system software wants to access them with integer code. (aarch64 uses long double type now) > I don't think it really makes any difference. Existing ABIs are not > going to be changed, and the consensus from people who actually want > to use IEEE quad seems to be that they want a __float128 type that's > uniform across archs, not having it for long double. This puts it > outside the scope of math library for the time being, and would > probably be a separate add-on math library if there eventually is a > math library for these since musl can't/won't depend on compiler > support for new/optional types to build a working libc.so (this would > preclude using any compiler without them). nowadays there is some support for ts 18661-3 in gcc so a libc can support the interfaces defined there (which include math functions for _Float128 type), an old draft: http://www.open-std.org/jtc1/sc22//WG14/www/docs/n1945.pdf however hw implementation is costly and with current implementations there is significant gap between double and quad prec performance so heavy uses of quad is unlikely even when available in hw. otoh quad prec software implementations are still much faster than arbitrary precision float libraries (mpfr, arb) so there are use cases when quad makes sense in general (but it might be better to just optimize the arbitrary precision libraries)