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

[E. Weddington]

Bernardo Innocenti wrote:

> E. Weddington wrote:
>
> > I think it would be great to integrate simulavr, or now known as 
> > simulavrxx (even though it is just an internal architecture change, 
> > there is new management at the simulavr project), and also integrate 
> > avarice. But also most importantly I would like to have a native 
> > Win32 version of both of those.
>
>
> You mean built with mingw or just not using cygwin1.dll?
> The latter is certainly possible by configuring in uberbaum
> with --target=avr, --host=i386-pc-mingw32 and --build=i386-pc-cygwin.
Yeah, I'm familiary with that. Technically, I build in Cygwin but use 
the -mno-cygwin flag with --host=i386-pc-mingw32 and 
--build=i386-pc-mingw32. (This lets me build in a Cygwin enivronment, 
with access to all of their libraries and build tools, but with a 
mingw32 compiler.)
But it doesn't cover all the cases. When a program uses POSIX calls, 
such as fork(), then you'll get linker errors because that function 
doesn't exist on a Windows/mingw32 platform. There needs to be a 
compatibility layer such as libiberty for gcc. Right now, there is not a 
compatibility layer for either simulavr or avarice. avrdude has a 
compatibility layer and that's why I can build a complete Win32 version 
of that software.


> > > 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 :-)
> >
> >
> > Well, that's what documentation is for. ;-) See the avr-libc user 
> > manual for more info.
>
>
> It's too bad Google didn't find it for me... Maybe that
> would be a good reason for making avr-libc documentation
> available online? :-)

It's always been online. :-)

Go to the avr-libc project on Savannah:
<http://savannah.nongnu.org/projects/avr-libc/>
Follow the link to the Project Homepage:
<http://www.nongnu.org/avr-libc/>
Under the "Documentation" heading is a link to the Online Users Manual:
<http://www.nongnu.org/avr-libc/user-manual/index.html>

If you would lurk on the avr-gcc-list mailing list:
<http://avr1.org/mailman/listinfo/avr-gcc-list>
Or, If you would lurk on the forums at AVR Freaks:
<http://www.avrfreaks.net/>
Then you would have found this out. ;-)

And all of these links are in the WinAVR README file.... If you use 
Windows...

> > > 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.
> >
> >
> > I don't know how generic it could be made until GCC actually has a 
> > generic way of specifying different memory spaces. Right now those 
> > routines make use of macros in avr-libc to access (read) the program 
> > memory space of the AVR.
>
>
> Even with GCC support, functions woud have to be built twice and
> made available with and without the _P suffix (in C++ we could have
> used overloading).
That's the way they're done now: regular functions, and functions with 
the _P suffix. It seems to work just fine.

> This is a trick I use in our projects to prevent massive code
> duplication, while abstracting the CPU type:
>
> <snip>
>
> A similar technique could be used in newlib/libgloss.

We have to remember the KISS rule. It's been hard enough for a number of 
users just to get used to the idea of seperate memory spaces and how 
things get stored there and how to read data out of the Program Space.

Any move from avr-libc to newlib would have to be seamless in the 
beginning, and for the most part backwards compatible. Obviously, you're 
free to do whatever method works for you, though.


> > > - newlib uses a funny documentation format, avr-libc uses doxygen;
> >
> > I'm perfectly willing to drop doxygen. In my mind it is too 
> > restrictive. Joerg will have to state his opinion.
>
>
> The fancy documentation tool used in newlib appears to follow
> Doxygen's philosophy, while using an ugly syntax.  I've never
> seen what the formatted output looks like, but I'd bet it's not
> on par with Doxygen's.
>
> libstdc++ already uses Doxygen, so I'd rather adapt newlib
> than avr-libc.
I'm not sure what you mean by you'd "rather adapt newlib than avr-libc": 
adapt newlib to what?

The Doxygen tool was just supposed to be a convenient way to generate a 
function reference and to generate 3 major formats: HTML, PS, and PDF. 
But there are some major drawbacks. Joerg can tell you more about the 
problems. The main issue that I have with Doxygen is that the avr-libc 
user manual is more than just a "function reference"; there are a lot of 
other good things in there that don't neatly fit into the Doxygen 
system. The avr-libc user manual is not very well organized, and it 
becomes difficult to find information.

I would propose moving the avr-libc user manual to perhaps a Docbook 
format. Yes, it would mean rewriting all of the function reference 
again. But it only has to be done once. Then there can be some semblence 
of order and flow to the user manual.

If avr-libc was moved to newlib, then we'd have to see what kind of docs 
newlib generates. The avr-libc user manual, then might become an "AVR 
toolchain user manual".

Food for thought....
Eric