Re: [avr-gcc-list] generic queue library for AVR GCC?

[E. Weddington]

David Brown wrote:

> > David Brown wrote:
> >
> >    
> >
> > > Personally, I'd like to see the addition of a "critical" function
> > >      
> attribute,
>  
>
> > > like in mspgcc.  It is clearly readable, avoids any requirements for
> > >      
> extra
>  
>
> > > local variables, generates optimal code, and generates any required "goto
> > > out" automatically.  You can use it on inlined functions to avoid
> > >      
> function
>  
>
> > > call overheads if you want.
> > >
> > >
> > >      
> > I think that's a *great* idea!
> >
> > Personally, I don't care for all the methods that have been proposed on
> > this thread that "hide" the manipulation of SREG (various macros, etc.),
> > because of the very reason that they can be too easily be the causes of
> > some bad behaviour unless someone is vigilant about using them. I
> > generally prefer to be explicit about it.
> >
> > *But*, if there is a reasonable way to have the compiler enforce good
> > behaviour, such as the "critical" function attribute proposed above,
> > then I think that beats out all other methods.
> >
> > My $0.02.
> >
> > Eric
> >
> >    
>
> The mpsgcc folk have a few other function attributes (see
> http://mspgcc.sourceforge.net/manual/x877.html ).  Of course, their use of
> "signal" and "interrupt" is the opposite of in avrgcc, which could be
> confusing for people who use both.
>
>  
=:-o

Personally, I've never liked the "interrupt" function attribute. I've 
never used it, and don't ever see a need to. And it's *terribly* 
confusing to newbies, and especially those that don't come from a Unix 
background, which is most people who use WinAVR.

I'm open to somebody giving me a credible reason to having it around, 
but if none is forthcoming, I could possibly support removing it.

> As a more general idea, it strikes me that there is a lot of duplication of
> effort in the two gcc ports.  At the very least, it's worth each group
> looking at the other's project and seeing how they solve different
> problems - copying ideas, documentation and code when possible.  There has
> also been some suggestions on the mspgcc mailing list of using (all or part
> of) avr-libc with mspgcc.
>  
Hmm, big problem there. Most of avr-libc has been "optimized" by 
implementing it in AVR assembler. IIRC, the stdio stuff is still in C 
(and probably will remain that way). I know all the math library is in 
AVR assembler. So there wouldn't be much to port. Your best bet would be 
to port stuff from newlib.

Eric