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

[E. Weddington]

Bernardo Innocenti wrote:

> E. Weddington wrote:
>
> > Bernardo Innocenti wrote:
>
>
> 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.
Sure, if that's what simulavr and avarice need. Also, it just needs a 
volunteer who has the time and ability to go through it.


> > Or, If you would lurk on the forums at AVR Freaks:
> > <http://www.avrfreaks.net/>
> > Then you would have found this out. ;-)
>
>
> Double Doh! :-)

Note, that the forums on AVR Freaks have been cracked recently. Someone 
has taken advantage of a php security bug and is redirecting... :-( 
Hopefully the webmasters will have this fixed soon.

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

What kind of stuff does it need to use?

> We also had to rebuild GNU make with a patch to
> fix a Cygwin/Mingw specific bug.
I'm interested: what kind of bug?
Does it affect the mingw make 3.80?


> 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).
*Any* testing with the avr port for 4.0 is badly needed and any bugs 
reported so they can be fixed! Thanks!


> > 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.
Writing the sources twice hasn't been a problem; they get written one 
time and then it's good to go.


> 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.
AFAIK, GCC does *not* have any support for different program spaces 
(i.e. Harvard Architecture). IIRC, Svein Seldal said he was going to 
write a patch to add this to GCC, but it was going to take some time. We 
haven't heard from him about this patch in a while.

Having this feature would be fantastic; it would be nice to have the 
compiler be able to generate the LPM instruction sequence, and have 
pointers to different memory spaces.


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

Sure, but at least it is documented that it is awkward. And it's very 
explicit too. The user really knows what is happening with the data.

> > > 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.
Oh, ok. Joerg and I have talked recently about the limitations of 
Doxygen though.

> > 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.
There's always the possibility that the documentation could get out of 
sync whether it was embedded in the code or elsewhere. I feel that the 
best thing is to have a clear policy that is followed: update the code, 
update the documentation, or the change doesn't go in.

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

If there were transformations that were clear and that don't change 
(PDF, HTML) then I think that it would be alright. I don't think we're 
looking for anything fancy (except perhaps being able to embeded a 
handlful of graphics). We would just like to have control over the order 
of the presentation.

Eric