From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id F0E243858427 for ; Fri, 26 Aug 2022 17:45:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0E243858427 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661535943; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=oxTOZMhL66S9D82mjn3ua03Jw9Z4YozH5nTwjt19Nlg=; b=foRrYwaH8/ZNfMuNTRfgyaPhVLETdc9Z6VhFo+i4mGBd7yqpnEkJytgeaAFP33F8hpmSbj i+Pm4B0l5wM73OUlivuT4/H9lxP3m1ePOSLGdEBaU1BQVSoXvfbTI14MAOzUegGT0HPJ+C g6NyeCTgo/89bFIRljzpgm0pW3nKNyk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-214-O3-Gjs9COUmBeHSTVNXP7w-1; Fri, 26 Aug 2022 13:45:42 -0400 X-MC-Unique: O3-Gjs9COUmBeHSTVNXP7w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EC1503815D37 for ; Fri, 26 Aug 2022 17:45:41 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.193.176]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD1572166B29 for ; Fri, 26 Aug 2022 17:45:41 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 866F5A806D1; Fri, 26 Aug 2022 19:45:40 +0200 (CEST) Date: Fri, 26 Aug 2022 19:45:40 +0200 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <20220822225022.32209-1-joel@rtems.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Aug 26 10:45, Joel Sherrill wrote: > On Fri, Aug 26, 2022 at 10:05 AM Corinna Vinschen > wrote: > > No, I wrote, create a *single* _fpmath.h file with the massive amount > > of definitions (*all* seven) based on LDBL_MANT_DIG. > > > > There are very few special targets, like x86/x86_64 which need a tweak > > in the macros, most of the time the macros should be the same. > > > > Instead of having 61 files, only have one. In theory there should be > > only two definitions for targets with LDBL_MANT_DIG == DBL_MANT_DIG > > to support little and big endian, more shouldn't be required. > > > > For all others, we already have *ieee*.h files with matching definitions > > which can be used as role models for the various (but few) definitions of > > union IEEEl2bits. See, for instance, newlib/libc/include/machine/ieee.h. > > > > > This approach works and doesn't abandon the targets which the > > > ldbl==dbl method works for. > > > > I never said to abandon these targets, but fwiw, I think you're > > overestimating the complexity to generate a single _fpmath.h > > file with matching definitions for these targes as well. The > > information is basically already present in newlib. > > > So don't preserve the FreeBSD files as close to a direct copy > as possible? We're only talking about the _fpmath.h files, not all the other files. If you like, copy over the handful of target-dependent _fpmath.h files, but *also* add a generic _fpmath.h file for all other targets, IMHO. > Maybe I am overestimating it. I just don't see the single _fpmath.h > to rule them all with confidence like you do. I am not seeing the > set of parameters in my head which makes this generic with > some macros. > > I'd appreciate help on this. newlib/libc/include/machine/ieee.h does not help? Kind of like this: #if LDBL_MANT_DIG == 24 union IEEEl2bits { long double e; # ifdef __IEEE_LITTLE_ENDIAN struct { __uint32_t manl :16; __uint32_t manh :7; __uint32_t exp :8; __uint32_t sign :1; } bits; struct { __uint32_t manl :16; __uint32_t manh :7; __uint32_t expsign :9; } xbits; # else struct { __uint32_t sign :1; __uint32_t exp :8; __uint32_t manh :7; __uint32_t manl :16; } bits; struct { __uint32_t expsign :9; __uint32_t manh :7; __uint32_t manl :16; } xbits; # endif }; # define LDBL_NBIT 0 # define LDBL_IMPLICIT_NBIT # define mask_nbit_l(u) ((void)0) # define LDBL_MANH_SIZE 7 # define LDBL_MANL_SIZE 16 # define LDBL_TO_ARRAY32(u, a) do { \ (a)[0] = (uint32_t)(u).bits.manl \ | ((uint32_t)(u).bits.manh << LDBL_MANL_SIZE) \ (a)[1] = 0; \ } while(0) #elif LDBL_MANT_DIG == 53 union IEEEl2bits { long double e; # ifdef __IEEE_LITTLE_ENDIAN struct { __uint64_t manl :32; __uint64_t manh :20; __uint64_t exp :11; __uint64_t sign :1; } bits; struct { __uint64_t manl :32; __uint64_t manh :20; __uint64_t expsign :12; } xbits; # else struct { __uint64_t sign :1; __uint64_t exp :11; __uint64_t manh :20; __uint64_t manl :32; } bits; struct { __uint64_t expsign :12; __uint64_t manh :20; __uint64_t manl :32; } xbits; # endif }; # define LDBL_NBIT 0 # define LDBL_IMPLICIT_NBIT # define mask_nbit_l(u) ((void)0) # define LDBL_MANH_SIZE 20 # define LDBL_MANL_SIZE 32 # define LDBL_TO_ARRAY32(u, a) do { \ (a)[0] = (uint32_t)(u).bits.manl; \ (a)[1] = (uint32_t)(u).bits.manh; \ } while(0) #elif LDBL_MANT_DIG == 64 union IEEEl2bits { long double e; # ifdef __IEEE_LITTLE_ENDIAN struct { __uint64_t manl :32; __uint64_t manh :32; __uint64_t exp :15; __uint64_t sign :1; __uint64_t junk :16 } bits; struct { __uint64_t man :64; __uint64_t expsign :16; __uint64_t junk :16 } xbits; # else struct { __uint64_t junk :16 __uint64_t sign :1; __uint64_t exp :15; __uint64_t manh :32; __uint64_t manl :32; } bits; struct { __uint64_t junk :16 __uint64_t expsign :16; __uint64_t man :64; } xbits; # endif }; # define LDBL_NBIT 0x80000000 # define mask_nbit_l(u) ((u).bits.manh &= ~LDBL_NBIT) # define LDBL_MANH_SIZE 32 # define LDBL_MANL_SIZE 32 # define LDBL_TO_ARRAY32(u, a) do { \ (a)[0] = (uint32_t)(u).bits.manl; \ (a)[1] = (uint32_t)(u).bits.manh; \ } while(0) #elif LDBL_MANT_DIG == 113 union IEEEl2bits { long double e; # ifdef __IEEE_LITTLE_ENDIAN struct { __uint64_t manl :64; __uint64_t manh :48; __uint64_t exp :15; __uint64_t sign :1; } bits; struct { __uint64_t manl :64; __uint64_t manh :48; __uint64_t expsign :16; } xbits; # else struct { __uint64_t sign :1; __uint64_t exp :15; __uint64_t manh :48; __uint64_t manl :64; } bits; struct { __uint64_t expsign :16; __uint64_t manh :48; __uint64_t manl :64; } xbits; # endif }; # define LDBL_NBIT 0 # define LDBL_IMPLICIT_NBIT # define mask_nbit_l(u) ((void)0) # define LDBL_MANH_SIZE 48 # define LDBL_MANL_SIZE 64 # define LDBL_TO_ARRAY32(u, a) do { \ (a)[0] = (uint32_t)(u).bits.manl; \ (a)[1] = (uint32_t)((u).bits.manl >> 32); \ (a)[2] = (uint32_t)(u).bits.manh; \ (a)[3] = (uint32_t)((u).bits.manh >> 32); \ } while(0) #endif There's also a ___IEEE_BYTES_LITTLE_ENDIAN definition which I ignored for now. Also, the LDBL_MANT_DIG == 64 is defined for x86-only and the manl/manh fields for LDBL_MANT_DIG == 23 are faked on a 16 bit border just to have a manl and a manh definition. I don't claim that it works OOTB with the above, but apart from the LDBL_NBIT/mask_nbit_l values which differ for x86/x86_64 CPUs, it should be a good start, I think. > > Jeff, ping? Your POV would be much appreciated here. > > > > +1 > > I also have come across there needs to be a way to pick between ld80 > and ld128 headers and implementation files. FreeBSD has them in > separate directories. Apparently their build system builds common > plus an architecture specific _fpmath.h and a choice of ld80/ld128 > which adds at least two other header files But then again, FreeBSD supports ARM and PowerPC, both of which come with 64 bit long double. So, besides ld80/ld128, there's apparently a generic implementation, too, to support non-ld80 and non-ld128 long double, right? Corinna