Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0

[E. Weddington]

Joerg Wunsch wrote:

> As Bernardo Innocenti wrote:
>
>  
>
> > Toolchain distributors would still need to add some AVR-specific
> > headers for register definitions and asm macros, which wouldn't be
> > appropriate for inclusion in newlib.
> >    
>
> That sounds bad.  Do you really think it's feasible to offload this to
> ``toolchain distributors''?  No centralized repository for it, where
> it can be coherently maintained regardless of the person who is
> shipping the toolchain?  Right now, you can at least shuffle an
> AVR-GCC project back and forward between Windows & Linux & FreeBSD (&
> Solaris & MacOS X) without any need to change your code (and if you
> design it that way, hopefully even with the same Makefile).  This
> would seem a much more important source code compatibility issue in my
> opinion than a hypothetically increasing probability to port an AVR
> project to an ARM7 or such.
>
> I strongly disagree with that aspect.  Why couldn't this be integrated
> into newlib as well?  All these header files purposely go into an avr/
> subdirectory already anyway.  Otherwise, we end up with one CVS repo
> for newlib and one CVS repo for the avr-specific header files, which
> would be no different than the current situation.
>
>  

I very strongly agree with Joerg on this as well.

I'm certainly not against moving avr-libc into newlib, provided:

1. CVS commit policy was reasonable. I don't have any reason to suspect 
that it is *not* reasonable, but I am not familiar with their policies.
2. AVR-specific headers and library code can be easily integrated, thus 
no burden on "toolchain distributors", _me included_. :-)

To give a very concrete example of #2, in avr-libc there is avr/boot.h 
which provides an API for creating bootloaders using the (mega) AVRs 
bootloader feature. This is certainly a valuable piece of work that IMO 
should not get lost when moved over to newlib, and toolchain 
distributors should not be burdened with having to provide it seperately 
or maintaining a seperate repository for it. Another important example 
is all of the avr-libc string functions that work with Program Space 
parameters.

As a potential #3 condition, it would be nice to be able to provide 
standard routines that are optimized for the AVR (read written in AVR 
assembly) that would be used in place of generic newlib functions 
written in C. For example, it would be nice to move the string functions 
that are currently in avr-libc (and written in AVR assembly) and have 
those be used for the AVR port in place of the string functions that 
normally come with newlib. Unless, of course, it can be shown that the 
compiled C function is comparable to the hand-written assembly. The 
point being, I don't want the size of the resulting library to be 
significantly bigger than what is done with avr-libc.

I definitely see advantages to moving to newlib. Obviously access to 
functions that aren't currently included in avr-libc. Support for 
RTOSes, which definitely include RTEMS. As I understand it (somebody 
correct me if I'm wrong), support for specific boards can be put into 
libgloss, and this would definitely help for a lot of people who make 
their own boards (such as perhaps Brian Dean's MAVRIC board, or more 
importantly the whole TinyOS contingent).

I would certainly like that the current maintainers/developers of 
avr-libc have CVS write permission for the AVR port in newlib and 
designated as co-maintainers of the AVR port.

Ralf, Bernie, you both have had more experience with newlib than I have, 
does all of this sound reasonable? Is there anything that we're not 
thinking of here?

Ralf, this could very potentially help your effort out with RTEMS, correct?

Eric