mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Damian McGuckin <damianm@esi.com.au>
To: musl@lists.openwall.com
Subject: Re: [musl] Considering x86-64 fenv.s to C
Date: Sat, 18 Jan 2020 16:03:01 +1100 (AEDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.2001181545420.21223@key0.esi.com.au> (raw)
In-Reply-To: <20200118011535.GD23985@port70.net>

On Sat, 18 Jan 2020, Szabolcs Nagy wrote:

> * Markus Wichmann <nullplan@gmx.net> [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

  reply	other threads:[~2020-01-18  5:03 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:30 Damian McGuckin
2020-01-16 15:11 ` Markus Wichmann
2020-01-16 16:14 ` Rich Felker
2020-01-16 18:56   ` Damian McGuckin
2020-01-16 19:33     ` Rich Felker
2020-01-16 21:31       ` Damian McGuckin
2020-01-17  3:36       ` Damian McGuckin
2020-01-17  3:48         ` Damian McGuckin
2020-01-17  3:53         ` David Edelsohn
2020-01-17 14:13           ` Rich Felker
2020-01-17 14:19             ` David Edelsohn
2020-01-17 14:53         ` Rich Felker
2020-01-18  4:45           ` Damian McGuckin
2020-01-18  5:29             ` Rich Felker
2020-01-19  8:50               ` Damian McGuckin
2020-01-19  9:07           ` Damian McGuckin
2020-01-19 10:42             ` Szabolcs Nagy
2020-01-19 12:25               ` Damian McGuckin
2020-01-20  5:32           ` Damian McGuckin
2020-01-20 17:38             ` Rich Felker
2020-01-20 21:11               ` [musl] Triggering Overflow (or Underflow) without triggering Inexact on i386 Damian McGuckin
2020-01-20 22:32                 ` Szabolcs Nagy
2020-01-21  3:53           ` [musl] Considering x86-64 fenv.s to C Damian McGuckin
2020-01-21  4:22             ` Rich Felker
2020-01-21  4:46               ` Damian McGuckin
2020-01-21  7:26                 ` Damian McGuckin
2020-01-17 16:41         ` Markus Wichmann
2020-01-18  1:15           ` Szabolcs Nagy
2020-01-18  5:03             ` Damian McGuckin [this message]
2020-01-18  5:37               ` Rich Felker
2020-01-18  9:40                 ` Szabolcs Nagy
2020-01-24  0:42                   ` Damian McGuckin
2020-01-24  1:11                     ` Rich Felker
2020-01-24  4:13                       ` Damian McGuckin
2020-01-24  4:55                         ` Rich Felker
2020-01-24  6:08                           ` Damian McGuckin
2020-01-24 13:44                             ` Rich Felker
2020-01-24 14:45                               ` Damian McGuckin
2020-01-24 23:59                               ` Damian McGuckin
2020-01-25  0:11                                 ` Rich Felker
2020-01-26  3:28                                   ` Damian McGuckin
2020-01-26  3:28                                   ` Damian McGuckin
2020-01-26  3:30                                   ` Damian McGuckin
2020-01-26  3:32                                   ` Damian McGuckin
2020-01-26  5:25                                   ` Damian McGuckin
2020-01-27  3:32                                   ` Damian McGuckin
2020-01-27  5:39                                   ` Damian McGuckin
2020-02-02  0:47                                   ` Damian McGuckin
2020-02-03  0:54                                   ` Damian McGuckin
2020-02-03  2:09                                     ` Rich Felker
2020-02-03  2:12                                       ` Damian McGuckin
2020-02-22 20:17                                         ` Rich Felker
2020-02-22 20:53                                           ` Damian McGuckin
2020-02-23  5:41                                           ` Damian McGuckin
2020-02-23  6:25                                             ` Rich Felker
2020-02-23  8:35                                               ` Damian McGuckin
2020-02-07 21:25                                   ` Damian McGuckin
2020-02-07 21:38                                     ` Rich Felker
2020-02-07 23:53                                       ` Damian McGuckin
2020-02-09  5:04                                       ` Damian McGuckin
2020-01-24  7:10                           ` Damian McGuckin
2020-01-18  5:04             ` Markus Wichmann
2020-02-03 14:16 [musl] PPC64(LE) support in musl requires ALTIVEC Romain Naour
2020-02-03 14:50 ` Rich Felker
2020-02-05  1:32   ` [musl] Considering x86-64 fenv.s to C Damian McGuckin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.2001181545420.21223@key0.esi.com.au \
    --to=damianm@esi.com.au \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).