[RFC] libm file structure modification

[Andoni Arregui - GTD-GmbH]

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