[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-libc-dev] Feature wishlisht

From: Weddington, Eric
Subject: RE: [avr-libc-dev] Feature wishlisht
Date: Fri, 25 Feb 2011 12:44:23 -0700

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Joerg Wunsch
> Sent: Friday, February 25, 2011 11:08 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] Feature wishlisht
> 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).

On the other hand, I don't like it as an option. -mint8 already breaks 
avr-libc. I would rather see 64-bit doubles, 32-bit floats, and library 
routines to support the user who can then decide which routines to use. Don't 
make it optional, as that would mean some toolchains in the field with one set 
of features, others with another set of features. I think this would just lead 
to maintenance problems.

As an admittedly weird side-benefit: IIRC, I think that all we need is to 
implement 64-bit doubles in order to build the Fortran compiler of GCC for the 
AVR target. That is if anyone really cares about writing Fortran for the AVR. 

> I think the standard feature set of avr-libc is pretty much settled,
> and does not call for many more extensions.  (Disclaimer: that's my
> very personal opinion.)

And in my opinion, there are other things that we can do to improve and extend 
avr-libc even more. 

IIRC, there are some routines that we could add to improve XMEGA support, 
including some of those "timed sequences" inline assembly routines.

We also talked about making avr-libc build "per device", instead of build per 
architecture like we do now. Did that get ever fully settled?

Anitha, there is also a TODO file in the source tree (I think under /doc) which 
contains a lot of old ideas that we've had over the years.

I still want to do the "corelib" project, but that would technically be in 
addition to avr-libc, not a part of it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]