As Tobias Frost wrote: > currently I have to do an estimation how much time it will take to > implement double maths to the avr-libm. Based on the outcoming > estimation, it might happen that the company will sponsor this.
Perhaps Dmitry can answer that. Note that parts of our libm.a functionality rather belongs into libgcc.a because they are implementing GCC auxiliary functions. > Well, I have no idea, how much work the adaption of the GCC will be, > and -- beside the implementation of the math itself --. Implementing them into GCC is the first step needed so. You could have 64-bit doubles in GCC without an accompanying libm.a, but you could not (usefully) starting to implement a 64-bit FP math library without compiler support for the number format. It is probably not too hard to implement, but as usual: Der Teufel steckt im Detail. I'd also like to have it as an option similar to -mint8, say -mdouble32, defaulting to 64-bit doubles, so the compiler is by default compliant to the C standard, yet we expect most AVR users to simply put -mdouble32 into their Makefiles then. Just as an idea: sizeof() float double long double -mdouble32 4 4 8 default 4 8 8 That would give people some flexibility to have 64-bit FP numbers even when using -mdouble32 (by using long double). Of course, the library mess has to be sorted out, too: not only the correct libm.a needs to be selected depending on -mdouble32, but functions from the standard library dealing with FP numbers (strtod() comes to mind) also have to work correctly. That could perhaps be handled with some preprocessor tricks that divert the actual strtod() to some internal __strtod32(), or __strtod64(), respectively. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev