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

[Bernardo Innocenti]

E. Weddington wrote:
> Joerg Wunsch wrote:
> > As Bernardo Innocenti wrote:
> >
> > 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.

At least they don't demand signing legal papers as FSF projects do :-)


> 2. AVR-specific headers and library code can be easily integrated, thus 
> no burden on "toolchain distributors", _me included_. :-)

I hope they will, but as a toolchain distributor you'd at least
get binutils + GCC + newlib + GDB all built together.  This is
already possible today, except that libgloss breaks the build
and newlib must be replaced with avr-libc at a later stage.

This page describes the procedure:

 http://gcc.gnu.org/simtest-howto.html

Integrating simulavr so we could run GCC's regression tests
on the AVR would be great (mainline no longer broken every
few weeks without anyone noticing).


> 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,

If only I knew about that a few months ago... We almost
rewrote Atmel's bootloader application-note which was based
on IAR's compiler and used a MS Excel document with VBA
macros as a replacement for autoconf :-)


> 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.

If these could be made a little more generic, they would be
very useful on many Harvard processors.  The RTEMS people
may like to have something like that in newlib.


> 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.

A quick look at newlib's source base reveals that they have
very little code in machine-specific directories.  I don't
know if it's due to a policy of keeping non-portable code
to a bare minimum or if it's just lack of contributions.


> 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'm not sure... AFAIK libgloss is totally undocumented...
I had assumed it was some framework used by simulators to
simulate existing boards, but perhaps I'm confusing
it with the "sid" project (also part of the src repository).


> 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.

I'm not a regular newlib contributor, so I don't know
what to expect.


> 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?

- newlib and avr-libc have different licenses, altough it seems
  newlib already includes a few GPL'd files in their codebase
  and many avr-libc sources still bear the 3-clause BSD license
  header.

- newlib uses a funny documentation format, avr-libc uses doxygen;

- newlib uses an inconsistent coding style (somewhere it's GNU's,
  somewhere it's K&R/BSD).  avr-libc is K&R/BSD.

- many files from newlib and avr-libc appear to have a common root.
  Both libraries have a very similar structure (for example, see
  avr-libc/libc/stdlib/strtoul.c and newlib/libc/stdlib/strtoul.c);

Merging that much code would take time, but at this time I can't
see a single reason that would make it hard or impossible.

A possible strategy could be that one or more developers could
start diffing sources and submit bugfixes/enhancements to the
appropriate project, either newlib or avr-libc.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/