RE: [avr-libc-dev] Feature wishlisht

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Boyapati, Anitha
> Sent: Friday, February 25, 2011 12:28 PM
> To: Joerg Wunsch; address@hidden
> Subject: RE: [avr-libc-dev] Feature wishlisht
> 
> >Yes, libstdc++ support is on the wishlist, even though it's beyond the
> >scope of the avr-libc project.
> 
> Here comes my basic question - we do have libstdc++ in gcc already.
> However we are not building it for AVR-8 as of now. So what is the
> requirement for another library? To me it appears that libstdc++ can be
> built with a bootstrapped compiler (if it is possible).

No, no, no. We don't mean it as a *new*, separate library. We do mean it as you 
said: Building libstdc++ that comes with GCC.

If it was easy, we would have already done it by now. ;-) Both Joerg and I have 
looked into doing this many years ago. It doesn't seem straightforward, and 
both of us ran out of time to look into it. You have to remember that many 
years ago, there weren't that many C++ users on the AVR. Perhaps, now that some 
time has passed, there are enough C++ users on the AVR to warrant the time to 
look deeper into how to get that darn library built for the AVR.

If you have some ideas on how to do this, then it would certainly be 
appreciated. :-)
 
> >Likewise, 64-bit doubles are on the wishlist (as an option to the
> >current implementation), but again, this is much of a compiler issue
> >rather than library only.  My preference would be a compiler option
> >much like we've got -mint8, so perhaps "-mdouble32" which enables the
> >current behaviour, defaulting to double being 64 bits as this is what
> >the ISO C standard asks for (well, sort of, but they're asking for
> >*more* than 32-bit FP for the "double" datatype, and while 48 bits
> >would satisfy their requirements, it's IMHO not possible to implement
> >a 48-bit datatype in GCC).
> 
> This is still a mystery to me. When BITS_PER_UNIT/WORD is modified, the
> sizes of INT/LONG get affected. Implementing 48-bit double is definitely
> not straight forward (or may be not possible? To be confirmed)

No, not 48-bit double. We want full-blown 64-bit doubles.