From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1872 invoked from network); 4 Sep 2022 19:53:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Sep 2022 19:53:03 -0000 Received: (qmail 7233 invoked by uid 550); 4 Sep 2022 19:52:59 -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 7201 invoked from network); 4 Sep 2022 19:52:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=VwNCUELbNSbmrI85z/jFMIoqD1lDYMrp5rCvZZI5B/o=; b=f9YcCYUpoZvlABMRx4JaLTciP8FxZd0v/zPRtq8o/FlBoTIyz2GjUGSB/rADXWFjv/ RHIkcoLcPodGJocBiwV1Zqp6gfIvQtbfqYFPsoVelGBZ2X3GwHq3HD2WpFbpetkEJJEk xMc3OIW0XNOQEvfWZcHLl3D8MkNEbOr3OpSAuZQYSNcT+nDG9Is/b2dqjOOI1QyZowje vZj0IWd/JuyCYIR3mIH5QnPXmbMVmzDmuSjhQBRnfzT9XmF6cr3YuG/mTMDwRelOQ+FW w1M0BSaIC6VahoDh8VqhnuBzWAyuSURFI8P7KC0ltT1UeGkNnJA0oPrmqCVHbPq4vlSd 1Gwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=VwNCUELbNSbmrI85z/jFMIoqD1lDYMrp5rCvZZI5B/o=; b=lqmMgx/MbmzpynmQHRqDq/78ktrO8MPKq5lcizH+SL0O6sbmZ33peCPBGcA9pUNCwD kAekbAp+Fk4Dl+iS2CW0iXonov7Zo7EqmZns60aymJaSxUZicTs1GX7LuXxuVSJ8wM80 kykbyiEFTkzQKjp3DmhDLxdWCOxr4Sxab6dQlL5z4fHGAVBbOHQjkZS3lkxOl6SBKUzW caP0qM14x3O9FVAv0o51KY9JN2CzHqMRf2L16REEo5AI0gJjduTVXOGNqJCGZiIUQwWT zKM+83yBMe2/akdNbVb5PF1qFUK65U4pCFZCICz4HN8e1Nq0bRbaUE0ydDzTF2zQuCPp 4qaw== X-Gm-Message-State: ACgBeo1muswW/itrMHFJ2P6uAMR9I0Ih2jIn7rRNHnTvDFH/gnTQxKul OTsJMlonqD+iRybOCfzDfAkznse/jzn+T8XxjiM= X-Google-Smtp-Source: AA6agR5hAi8YyjoQ/KZEQlKCKhylPvK1WvJwcF6YSRSY+wxJSaXBM2l3mFrvFXu+jpRXQ6dE0ZqRPRkvdWEg9zJgiQg= X-Received: by 2002:a1f:a6d3:0:b0:38c:c07d:60ae with SMTP id p202-20020a1fa6d3000000b0038cc07d60aemr12922176vke.17.1662321166834; Sun, 04 Sep 2022 12:52:46 -0700 (PDT) MIME-Version: 1.0 References: <20220819031934.GH7074@brightrain.aerifal.cx> <20220823173020.GJ7074@brightrain.aerifal.cx> <20220830122627.GA16467@brightrain.aerifal.cx> In-Reply-To: <20220830122627.GA16467@brightrain.aerifal.cx> From: ardi Date: Sun, 4 Sep 2022 21:52:35 +0200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Do you recommend using fmt_fp() and On Tue, Aug 30, 2022 at 2:26 PM Rich Felker wrote: > > I think the scaling just needs to be large enough to ensure we get out > of the subnormal range but not so large as to overflow. Since it's > conditioned on starting out with a negative exponent in the subnormal > range, you'd need an exponent much larger than the max positive > exponent for scaling to overflow, so 113 is safe and the only point of > the number being 113 is that it's sufficient for both formats. > > That's just my quick reading of what's going on, so if anyone thinks > I'm wrong about it, please speak up. I've left as it is, it seems to work fine. Aside from that, and as you pointed out, I needed a frexp() implementation for SoftFloat, and, because I want to have all things as complete as possible, I'm writing frexp() for all the types in SoftFloat (binary16, binary32 aka float, binary64 aka double, extended 80bit, and binary128). I'm just adapting the musl implementation so that it accesses the SoftFloat structs/unions. I'm having a hard time trying to understand the code block for "if(!ee)", specifically the decrement amount for the exponent. frexpl() decrements by 120 for both 80bit and binary128 long doubles. It makes sense because both types have the same exponent size. Then frexp() decrements by 64. It also seems to make sense because the exponent is smaller in binary64. However, frexpf() also decrements by 64. Why? And what's the reason for choosing 64 and 120? I couldn't find from where they come. For binary16 I'm replicating all the same logic, but no idea on the amount for decrementing the exponent on "if(!ee)". If I can understand how 64 and 120 where chosen for the other types, I'll be able to find it for binary16. Thanks again, C=C3=A9sar