From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by sourceware.org (Postfix) with ESMTPS id 482583858427 for ; Fri, 26 Aug 2022 15:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 482583858427 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-f53.google.com with SMTP id v2-20020a056830090200b006397457afecso581029ott.13 for ; Fri, 26 Aug 2022 08:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=8uSjmAClM0Gj9F4E8tApaKHxX2S/vy8ODygagy+g14E=; b=IBJAmszi9b0ANqjWgz8sS9X/eoHT30+dPJ14ENPcxgjSrSe4JBnkyYawZnGTh7xxBO J+GAwhrIBCiF4mL89KHhZFYL1zgzh2Vb2bw49yBAo6uWzajzP3Cy52uTSfesOkB+Mb9/ zJThTGL6FKvg1IZb1ikFWTSCFj12gu+ONELLldLBckKxF4MqM4mNupTeoobvrE9vG2y+ sMb8mLqq0kFG2+Mz9jJ2mhqzyJ63ZlI1z2pG6V3SRHDKKc933wQ6OJyi3g83x+bI1EBb SVpoYXMbpSofv2L86oRxPxVqEuyLWptCu/qlw1XtdYMalIOn4lMq5lYkirWINgYI1wLT TeFQ== X-Gm-Message-State: ACgBeo1KJr7+O5+2yS1kDu2d3l0n+w0ueP5Bvz4kyqyniF0+DrNZu6jb 9YStWzHkfYrvBKF4M20X64bkk39exnY= X-Google-Smtp-Source: AA6agR6vc/oEZuGkTSbQhQv1FA2nLBA7hFeuOVpgGxbesW2mCVkQ9/KY9Nu1KrDZlRT0Wt7rgYtGaA== X-Received: by 2002:a9d:7f91:0:b0:637:26ca:280e with SMTP id t17-20020a9d7f91000000b0063726ca280emr1617459otp.246.1661528732160; Fri, 26 Aug 2022 08:45:32 -0700 (PDT) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com. [209.85.167.172]) by smtp.gmail.com with ESMTPSA id j19-20020acaeb13000000b003432bb4322esm1152062oih.40.2022.08.26.08.45.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 08:45:31 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id t140so2430841oie.8 for ; Fri, 26 Aug 2022 08:45:31 -0700 (PDT) X-Received: by 2002:a05:6808:159:b0:343:aed:267d with SMTP id h25-20020a056808015900b003430aed267dmr1793935oie.185.1661528731102; Fri, 26 Aug 2022 08:45:31 -0700 (PDT) MIME-Version: 1.0 References: <20220822225022.32209-1-joel@rtems.org> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 26 Aug 2022 10:45:20 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions To: Newlib , Joel Sherrill , Jeff Johnston X-Spam-Status: No, score=-3031.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2022 15:45:35 -0000 On Fri, Aug 26, 2022 at 10:05 AM Corinna Vinschen wrote: > On Aug 24 08:40, Joel Sherrill wrote: > > On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen > > wrote: > > > > [...] > > > > if architecture has _fpmath.h > > > > use FreeBSD long double code in libm/common/ldbl > > > > else > > > > use existing long double code > > > > > > Erm... Did you actually read my last reply? > > > > > > Yes. If we do that, we end up with long double support on 8 > > architectures and lose it immediately on all others. On the > > 18 RTEMS target architectures, > > > > + Current: long double support on 12 > > + Proposed: long double support on all > > + Delete ldbl=dbl implementation: 8 would have long double > > > > > > We should really not add YA > > > code path. Merging the FreeBSD long double functions should work for > > > basically all supported arches. We only have to create our own > > > _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it? > > > > > > > It should if someone creates all the _fpmath.h headers. > > 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. > > > There are 61 > > directories under libc/machine. That leaves 53 _fpmath.h headers to > > complete and most are likely ldbl==dbl. That is up to 53 target > > architectures > > which would lose the long double math APIs in libm.a. > > > > Honestly, I don't mind long term planning to delete them but I was > > thinking this approach improves the current situation a lot since it will > > support the targets which really have long double support. It leaves > > in place support for where ldbl==dbl with no change in available APIs. > > It is a net win for users. > > > > If there is a target with long double which doesn't have a FreeBSD > > _fpmath.h file, then there is value in creating it. Honestly, unless > > someone > > can script writing the missing 50+ _fpmath.h files, I am not comfortable > > or eager to dive in. Ignoring the lack of time to so. > > > > 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? 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. > > 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 --joel > > > Thanks, > Corinna > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by sourceware.org (Postfix) with ESMTPS id 482583858427 for ; Fri, 26 Aug 2022 15:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 482583858427 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-f53.google.com with SMTP id v2-20020a056830090200b006397457afecso581029ott.13 for ; Fri, 26 Aug 2022 08:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=8uSjmAClM0Gj9F4E8tApaKHxX2S/vy8ODygagy+g14E=; b=IBJAmszi9b0ANqjWgz8sS9X/eoHT30+dPJ14ENPcxgjSrSe4JBnkyYawZnGTh7xxBO J+GAwhrIBCiF4mL89KHhZFYL1zgzh2Vb2bw49yBAo6uWzajzP3Cy52uTSfesOkB+Mb9/ zJThTGL6FKvg1IZb1ikFWTSCFj12gu+ONELLldLBckKxF4MqM4mNupTeoobvrE9vG2y+ sMb8mLqq0kFG2+Mz9jJ2mhqzyJ63ZlI1z2pG6V3SRHDKKc933wQ6OJyi3g83x+bI1EBb SVpoYXMbpSofv2L86oRxPxVqEuyLWptCu/qlw1XtdYMalIOn4lMq5lYkirWINgYI1wLT TeFQ== X-Gm-Message-State: ACgBeo1KJr7+O5+2yS1kDu2d3l0n+w0ueP5Bvz4kyqyniF0+DrNZu6jb 9YStWzHkfYrvBKF4M20X64bkk39exnY= X-Google-Smtp-Source: AA6agR6vc/oEZuGkTSbQhQv1FA2nLBA7hFeuOVpgGxbesW2mCVkQ9/KY9Nu1KrDZlRT0Wt7rgYtGaA== X-Received: by 2002:a9d:7f91:0:b0:637:26ca:280e with SMTP id t17-20020a9d7f91000000b0063726ca280emr1617459otp.246.1661528732160; Fri, 26 Aug 2022 08:45:32 -0700 (PDT) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com. [209.85.167.172]) by smtp.gmail.com with ESMTPSA id j19-20020acaeb13000000b003432bb4322esm1152062oih.40.2022.08.26.08.45.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 08:45:31 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id t140so2430841oie.8 for ; Fri, 26 Aug 2022 08:45:31 -0700 (PDT) X-Received: by 2002:a05:6808:159:b0:343:aed:267d with SMTP id h25-20020a056808015900b003430aed267dmr1793935oie.185.1661528731102; Fri, 26 Aug 2022 08:45:31 -0700 (PDT) MIME-Version: 1.0 References: <20220822225022.32209-1-joel@rtems.org> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Fri, 26 Aug 2022 10:45:20 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions To: Newlib , Joel Sherrill , Jeff Johnston Content-Type: multipart/alternative; boundary="000000000000cd389005e726cd66" X-Spam-Status: No, score=-3031.5 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20220826154520.c0KPiFY4YV7KCOevQi3tCJhFecUPTHWqraIDDO6tteE@z> --000000000000cd389005e726cd66 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 26, 2022 at 10:05 AM Corinna Vinschen wrote: > On Aug 24 08:40, Joel Sherrill wrote: > > On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen > > wrote: > > > > [...] > > > > if architecture has _fpmath.h > > > > use FreeBSD long double code in libm/common/ldbl > > > > else > > > > use existing long double code > > > > > > Erm... Did you actually read my last reply? > > > > > > Yes. If we do that, we end up with long double support on 8 > > architectures and lose it immediately on all others. On the > > 18 RTEMS target architectures, > > > > + Current: long double support on 12 > > + Proposed: long double support on all > > + Delete ldbl=dbl implementation: 8 would have long double > > > > > > We should really not add YA > > > code path. Merging the FreeBSD long double functions should work for > > > basically all supported arches. We only have to create our own > > > _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it? > > > > > > > It should if someone creates all the _fpmath.h headers. > > 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. > > > There are 61 > > directories under libc/machine. That leaves 53 _fpmath.h headers to > > complete and most are likely ldbl==dbl. That is up to 53 target > > architectures > > which would lose the long double math APIs in libm.a. > > > > Honestly, I don't mind long term planning to delete them but I was > > thinking this approach improves the current situation a lot since it will > > support the targets which really have long double support. It leaves > > in place support for where ldbl==dbl with no change in available APIs. > > It is a net win for users. > > > > If there is a target with long double which doesn't have a FreeBSD > > _fpmath.h file, then there is value in creating it. Honestly, unless > > someone > > can script writing the missing 50+ _fpmath.h files, I am not comfortable > > or eager to dive in. Ignoring the lack of time to so. > > > > 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? 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. > > 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 --joel > > > Thanks, > Corinna > > --000000000000cd389005e726cd66--