[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: E. Weddington
Subject: Re: [avr-gcc-list] generic queue library for AVR GCC?
Date: Thu, 18 Nov 2004 09:42:02 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

David Brown wrote:

David Brown wrote:

Personally, I'd like to see the addition of a "critical" function
like in mspgcc.  It is clearly readable, avoids any requirements for
local variables, generates optimal code, and generates any required "goto
out" automatically.  You can use it on inlined functions to avoid
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.


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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]