From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gtd-gmbh.de (mail.gtd.eu [46.24.46.35]) by sourceware.org (Postfix) with ESMTPS id 18B47386F425 for ; Wed, 27 May 2020 09:52:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 18B47386F425 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gtd-gmbh.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=prvs=1416a55e36=andoni.arregui@gtd-gmbh.de X-MDAV-Result: clean X-MDAV-Processed: gtd-gmbh.de, Wed, 27 May 2020 11:48:47 +0200 Received: from WorldClient by gtd-gmbh.de (MDaemon PRO v19.5.5) with ESMTPA id md50013856128.msg; Wed, 27 May 2020 11:48:47 +0200 X-Spam-Processed: gtd-gmbh.de, Wed, 27 May 2020 11:48:47 +0200 (not processed: message from trusted or authenticated source) X-MDArrival-Date: Wed, 27 May 2020 11:48:47 +0200 X-Authenticated-Sender: andoni.arregui@gtd-gmbh.de X-Return-Path: prvs=1416a55e36=andoni.arregui@gtd-gmbh.de X-Envelope-From: andoni.arregui@gtd-gmbh.de X-MDaemon-Deliver-To: newlib@sourceware.org Received: from [46.237.211.46] by gtd-gmbh.de via MDaemon Webmail with HTTP; Wed, 27 May 2020 11:48:44 +0200 Date: Wed, 27 May 2020 11:48:44 +0200 From: "Andoni Arregui - GTD-GmbH" To: newlib@sourceware.org Subject: [RFC v2] libm file structure modification (example file structure indent correction) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: X-Mailer: MDaemon Webmail 19.5.5 In-Reply-To: References: X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Wed, 27 May 2020 09:52:30 -0000 we (GTD) carried out a re-engineering and qualification activity on a subset of the Newlib libm for the European Space Agency (ESA) during the years 2016-2018, for the purpose of using it in on-going satellite projects (see for more details https://essr.esa.int/project/mlfs-mathematical-library-for-flight-software; NB: Access to the complete qualification data package is given persons in ESA member states that have registered to ESSR). We submitted the resulting patches to Newlib some weeks ago. Now, in the frame of a follow-on ESA project, we are going to do the same work but for all math.h functions (excluding the long double versions). Our target platforms are embedded systems in general, those used in spacecrafts in particular, and since many of them present special constraints regarding the CPU architecture (non superscalar architectures, limited caches, some with only 32 bit float FPU, etc.) we favor, and intend to keep and maintain corresponding implementations for all of them. Is it also the objective/intention of Newlib to provide a library for embedded systems or is this just a side effect? Since ARM contributed very welcome implementations in 2017 and 2018 and we expect that others may follow, we would like to propose a modification to the folder and file structure within the libm to better fit such contributions. The reason is that these contributions already had to break the old FDLIBM naming scheme and structure (e.g., the new files do not follow the w_*, s_*, k_*, e_* naming structure and are placed in the common folder) and the until then existing implementations were labeled as OBSOLETE_MATH, while still being perfectly valid, adequate and standard conform on many embedded systems. Maybe it is not the existing implementations which are obsolete but the old FDLIBM file naming and folder structure and we need a future proof structure to accommodate all contributions. As we are carrying out this activity for the space industry, we are very conservative with the existing code base and its heritage and thus, it is our intention to evolve the structure of the libm while keeping all implementations coexisting (see file/folder structure example below): - the 32 bit float implementations computed in 32 bit floats (required for FPUs that can only do 32 bit floats), - the 32 bit float implementations computed in extended precision such as 64 bit doubles (as the ones contributed by ARM, which are very performing on FPUs that can do 64 bit doubles), and - the several 64 bit double implementations (as the slower but smaller original polynomial approximation and the faster but bigger lookup-table based one contributed by ARM) Our activity includes the complete life-cycle data generation of the software (including the preparation of requirements, design, and test documents and verification and validation reports). This includes a complete description of the algorithms used in all implemented functions for a better understanding of what we have currently implemented. We trace all changes we carry out in a ticketing system and prepare the corresponding patches. We also develop a test suite to assess the implemented algorithms and validate their accuracy on ULP level and execution timing behavior. We would be happy to be able to contribute our results to the Newlib libm mainline and keep participating in the long term maintenance and thus, we want to ask if the Newlib community is ok with such a restructuring and the submission of this to the Newlib libm mainline. The following file/folder structure only includes the case for the sin, cos, and exp functions: libm / - common / (Functionality used in all implementations, e.g. macros to extract parts of the floating point numbers) + tools.c + tools.h - include / + math.h - machine / (subdirectory for each architecture with machine specific implementations of functions in math*) + arm / * mathd * ... + sparc / - mathd / + internal / * exp_table_data.c * sincosd_kernel.c (this contains old k_cos.c and k_sin.c) + cosd.c + expd_table.c + expd_poly.c + sincosd.c + sind.c - mathf / + internal / * sincosf_kernel.c (this contains old kf_cos.c and kf_sin.c) + cosf.c + expf.c + sincosf.c + sinf.c - mathfe / + internal / * sincosfe_data.c + cosfe.c + sincosfe.c + sincosfe.h + sinfe.c - mathl / + cosl.c + expl.c + sinl.c -- Andoni Arregi Geschäftsführer GTD GmbH Ravensburger Str. 32a, 88677 Markdorf T: +49 7544 96440 22 | M: +49 151 65620499 | F: +49 7544 96440 29 http://www.gtd-gmbh.de andoni.arregi@gtd-gmbh.de