Codesize of strtod/strtof/strtold is unreasonable large

[th-otto]

The code produced by those functions is about 9k each (a bit less for the -m68881 version). All three are referenced eg. by the scanf family of functions. Together with some floating support functions from libgcc.a, that alone adds about 30k of code to executables.

I think the current implementation (in strtod.c) is almost identical to the original one from glibc. I also think that most of the code is produced by the inlined mpn_* functions from gmp. So the question is: can that be reimplemented without gmp? I never understood why we need functions that can work on arbitrary long doubles, when we only have to work with a max. of 3 different, known sizes.

[mikrosk]

Good question. Wasn't that because glibc is (was) supposed to work on CPUs with non-standards FP types?

[th-otto]

That's possible, but we have already lots of other m68k/TOS dependencies in mintlib, so we don't have to worry about supporting little-endian formats or whatever. 30k is imho unacceptable for a single function. And that only accounts for strtod, i guess the other way (used in the printf functions) isn't much better.

[mikrosk]

I absolutely agree, I just meant that it was imported with such code and let as it was. I don't object against removing it, not at all.

[th-otto]

Its even worse than i thought. The definition in

mintlib/stdlib/strtod.c

Line 221 in 5919d04

#define MPN_VAR(name) mp_limb_t name[MPNSIZE]; mp_size_t name##size

will cause two local arrays to be used, with 38 (for double) and 518 (for long double) longs each. And the __mpn_mul etc. functions will operate on that large arrays. Additionally, the tables in https://github.com/freemint/mintlib/blob/master/stdlib/fpioconst.c will be needed, making up another ~3k of codesize.

I've looked also at other implementations, e.g from musl. They use only a single function for all three flavours, but that also compiles to ~10k of code. Additionally, it uses scalb() and some other functions from libm. That is something we definitely want to avoid (not only because of the codesize, but until now great care has been taken that mintlib does not have any references to libm)

So still looking for better implementations.

[th-otto]

See #69. Could you have a look?

(ignore the commit for the makefiles, that wasn't meant to be placed in that branch)