avr-gcc-list
[Top][All Lists]
Advanced

[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 10:03:46 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Dave Hansen wrote:

[...]


The "critical" attribute doesn't hide anything more or less than a decent
set of macros or inline functions.  It makes it harder to get it wrong,
which is a good thing. I suppose there is a danger of newbies mistakanly using "critical" when they really mean "I want this function to run as fast
as possible".


Such an attribute is useful if the critical section can be sensibly encapsulated in a function. I'm not completely convinced that is always the case. But in the project I'm currently working on, all the critical sections are encapsulated within functions.

Any single statement or multiple statements can be encapsulated in a function. The question of whether it is efficient to do so is a design decision.

It does invite abuse, however: it is harder to account the cost for code you don't write. To steal some of your code for an example:

  void addToBuffer(uint8 b) {
       CS_STATE_BUFFER csb;

       csb = begin_critical_section();

       if (length < bufferSize){
          buffer[(start + length) % bufferSize] = b;
          length++;
       }

       end_critical_section(csb);
  }

Given appropriate definitions of CS_STATE_BUFFER, begin_critical_section(), and end_critical_section(), this would generate code nearly identical to your original function. But it's easier to see the costs, and the implications of modifying the code. IMHO, anyway.


Again, having a "critical" function attribute would be an *addition* to what is available. People are free to use it, or not. They could still "roll their own" and make it explicit as your example above. I think that it would depend upon the coding standards one would use.

Eric


reply via email to

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