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 6ad0e8db for ; Sat, 18 Jan 2020 05:38:14 +0000 (UTC) Received: (qmail 3470 invoked by uid 550); 18 Jan 2020 05:38:12 -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 3447 invoked from network); 18 Jan 2020 05:38:11 -0000 Date: Sat, 18 Jan 2020 00:37:59 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200118053759.GX30412@brightrain.aerifal.cx> References: <20200116161427.GO30412@brightrain.aerifal.cx> <20200116193343.GP30412@brightrain.aerifal.cx> <20200117164143.GB2020@voyager> <20200118011535.GD23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Considering x86-64 fenv.s to C On Sat, Jan 18, 2020 at 04:03:01PM +1100, Damian McGuckin wrote: > On Sat, 18 Jan 2020, Szabolcs Nagy wrote: > > >* Markus Wichmann [2020-01-17 17:41:43 +0100]: > >>On Fri, Jan 17, 2020 at 02:36:20PM +1100, Damian McGuckin wrote: > >>>Also, and I could be wrong, currently MUSL assumes that there is an integral > >>>type for every floating type. > >> > >>Let me stop you there. Musl assumes that for long doubles, you can > >>create a union ldshape. So there is no need for a 128 bit data type, a > >>64 bit one is good enough. > > What does it assume for a long double which has 128-bits? Just that there's a struct ldshape defined for the specific long double type and endianness, that can be used to access its representation. > >actually it's quite annoying to deal with N bit long double > >without N bit int, because sometimes you want to fiddle with the > >bits using int operations and if you don't have N bit int type you > >have to deal with endianness (you can always copy the long double > >into an array of bytes, but the layout of the bytes is not > >portable, same for union with multiple fields: you need variants > >for different endianness) > > I was just seeking others experience and whether they is solution > about which I am unaware. But it seems not. I am looking at this > issues in the context of (purchasing) a Power9 CPU which has no > 80-bit floats but has instead 128-bit floats. The musl ABI for powerpc[64] uses 64-bit long double because the compiler support for IEEE quad is very lacking and was pretty much nonexistent at the time musl added these archs. > 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". > Are hardware versions of these on the horizon for Intel or others? > > Should we start lobbying the chip makers to get their act together?? > > Probably not questions to which I will get resolutions any time soon. 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). Rich