Hallo Jörg, Hallo Dimitry thanx for your replay. Tough I didn't find the time to answer.
However, it is going some steps forward: I got the ok and this week at work is dedicated to digg more into this. At the end of this, I need to tell who long it will take, and based on that, changes are good for some hacking for my favourite controller. ;-) The first step will to get in contact with Dimitry. Jörg, can you please trigger him or send me his contact data? I'm not sure if I found the "right" Dimitry on the list. (If his last name is Xmelkov, then my guess was right and he'll get a copy of this mail) Another thing to look at will be the gcc sources. Maybe there is some other controller to get inspired. Do you have a starting point, a contact or some other hints for me? > 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. I think you are right. I cannot tell right now, how much the customer intends to invest in this, so I cannot make the best solution "libm" the top priority. Pimping the libm can be done afterwards, especially if the budget is not exceeded at that time. > 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 The switch is a good idea. > 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. I agree with you. I'll keep that in mind and try to. Well, this also depends on the budget. I'll try to, but don't be disapointed if I unable to complete that. For the first shot, maybe just a "libm64" would be sufficient. So I now try to look up how to compile the gcc and libavr under Windows -- the "IT" here are all MS brainw.. certified. and won't allow me a Linux Box ;-( -- coldtobi http://blog.coldtobi.de 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro. Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
