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 798b0035 for ; Sat, 18 Jan 2020 05:03:16 +0000 (UTC) Received: (qmail 17569 invoked by uid 550); 18 Jan 2020 05:03:15 -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 17542 invoked from network); 18 Jan 2020 05:03:14 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs Date: Sat, 18 Jan 2020 16:03:01 +1100 (AEDT) From: Damian McGuckin To: musl@lists.openwall.com In-Reply-To: <20200118011535.GD23985@port70.net> Message-ID: References: <20200116161427.GO30412@brightrain.aerifal.cx> <20200116193343.GP30412@brightrain.aerifal.cx> <20200117164143.GB2020@voyager> <20200118011535.GD23985@port70.net> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [musl] Considering x86-64 fenv.s to C 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? > 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. As you say, it is annoying. I had this problem ages ago when a long was a 32-bit integer and a double was 64-bits. And now the problem has come back again. I find MUSL just so much more elegant that the old SUN library because MUSL no longer has to worry the get/set hi/lo twin pairs of macros and the soft arithmetic that was often necessary to support the 2 32-bit integers. 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. 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. Regards - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer