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

[Bernardo Innocenti]

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

Importing libiberty into a project is easy and supported by autoconf:
many GNU projects do that already (make, tar, bash...).

The master copy of libiberty is the one distributed with GCC.
If you make changes, make sure you submit patches.


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

Doh!


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

Double Doh! :-)


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

We primarly use Linux, but we also use Windows when I'm working
at my client's place for integration and debug.

We've ended up installing Cygwin too, because our Makefile uses
too much stuff.  We also had to rebuild GNU make with a patch to
fix a Cygwin/Mingw specific bug.


By the way, I've now started building with GCC 4.0, noticing
considerable reduction in code size (did not benchmark or
examine the asm output, though).  Building our C code with g++
also made the generated code very different (sometimes smaller,
sometimes bigger).


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

It's a lot of code duplication tough...  You can't avoid
wasting some ROM space, but you can at least avoid writing
the sources twice.


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

With GCC support for program-memory variables, at least we could avoid
using asm macros to fetch the data.  And we'd also get the pointers
correctly type checked.

Initializing static structures containing strings in program memory
is also awkward at the moment.


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

Initially, yes.  But in the long term, I'd rather use those macros or a
similar method instead of copying functions.  Many libraries for embedded
systems do this already.


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

I mean: using Doxygen instead of the FooBaz tool for newlib's
documentation.


> 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've found Doxygen's output too verbose and hard to customize,
but is there a better tool?  Documentation should be extracted from
the code, otherwise it would soon get out of sync.


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

I've been using DocBook for some time... then dropped it because
it requires too much typing, extending it is hard (XSLT) and
customizing its output is even harder (you must do it separately
for each output format, using different techniques).

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