Re: [avr-libc-dev] libm for doubles -- how much effort is needed?

[Tobias Frost]

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