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

[Bernardo Innocenti]

Ralf Corsepius wrote:

> > > The presence of a turn-key simulator as per simtest-howto.html
> > > makes it *immensely* more simple for others than hardware
> > > holders to regression-test their GCC changes, verify bugs and
> > > fix them.  So all the shouting from AVR enthusiasts is suggested
> > > be better spent getting an AVR simulator and a newlib port in
> > > the tree.
> >
> > The avr target uses avr-libc. 
>
> Wrong.
>
>
> > newlib has never
> > been ported to it
>
> newlib-cvs is generic enough to build out for the avr of the box and
> does not require further steps.

I've used avr-libc in some projects and it was generally good quality
and space efficient, but extremely limited in scope.

My guess is that newlib would be richer of functionality and perhaps
less efficient.  Space efficiency matters a lot on an 8-bit system
with RAM space ranging from 512byte to 8KB.

A long term goal could be merging intersting bits of avr-libc into
newlib and switching AVR toolchain distributions for Linux and Windows
to use newlib by default.

This would make AVR applications more portable while concentrating
development effort in a single C library.

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.


> ATM, there is one known bug in an RTEMS specific header, that needs to
> be looked after.
>
> > and libgloss even fails to compile
> > when I build in the uberbaum tree.
>
> RTEMS does not use libgloss.

Then it should be disabled in the top-level Makefile for the AVR
as I've done it in my local tree.  Shall I prepare a patch?

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