In my project I repeatedly call a function, it's 5 instructions. That helped in development, but now I figure it may be a hindrance.
Say that conserving memory is not a consideration - I will speed up execution overall if I just repeat the block of code in place of the function call, won't I?
Put another way, am I correct in reckoning that there's a certain "overhead" (extra time) that results from a function call?
Yes, there is overhead with functions, although do you really have such critical speed issues that it'll make a difference? If so, the inline directive is what you want - best of both worlds.
Critical speed issues? It may add up to enough.
"Inline Directive" - edify me.
"Inline Directive" - edify me.
That's google's job.
I used the forum search (inline directive) and turned up a dozen or so hits.
Two mentioned using inline directives, one made a half-hearted explanation (in a half-dozen words), neither provided an example.
Whereas googling for 'c inline directive' produced about 1700000 results, many of which looked quite useful.
I guess that I should just have known, somehow, to add a C in my search term.
I guess that I should just have known, somehow, to add a C in my search term.
Or C++. After all, you are looking for how to use "inline" with a specific language.
If the title of my Subject had been, "What's a inline directive?", I could get the sharp elbows.
But since this inline directive prospect came up in the course of conversation, and I kind of thought that's what's supposed to go on around here, having a conversation, I figured maybe I'd ask my good friend to drop the other shoe as it were.
I don't equate that with asking to be spoon-fed or having the world presented me on a silver platter. If someone had simply replied along the lines of, "Oh, that's where you... and then..." then I'd probably figure, 'Hmmm, grist for the mill there, mate. Thanks.'
From ISO/IEC 9899 (the C language standard) 6.7.4.5:
A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared only once. Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined.
I don't know how the directive is handled in C++ or the Arduino toolset, but if the time savings is essential, then it may be worth writing a macro containing the five instructions (statements?) and invoking the macro where needed.
There's a decent tutorial at http://www.cplusplus.com/, the inline specifier is described therein. Have not used it myself, but I believe it falls into the category of a "suggestion" to the compiler. The GCC compiler is pretty good at optimizing, I suppose it's possible that it could even decide to inline a function without being told. OTOH, there could be compiler switches that control whether it does or not. It'd be interesting to review the generated assembly language code to see what's really going on. If you happen to do that, we'd be interested in what you find!
Doesn't the Arduino IDE optimise for size over speed? If it does, I would think it would ignore the suggestion, unless you overrode the optimisation.
avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100
-Os = optimize for size.
I puzzles me why -g is used together with -Os...
dxw00d:
Doesn't the Arduino IDE optimise for size over speed?
Yes.
If it does, I would think it would ignore the suggestion, unless you overrode the optimisation.
Not always. I have no idea how the algorithm works but I know there are cases with the Arduino options when inline really does result in inlining. I also know that a static function called once always gets inlined.
There is a GCC compiler directive to force a function to always be inlined.
but now I figure it may be a hindrance
call --> 4 cycles
ret ---> 4 cycles
(4 + 4) * 5 / 16 = 2.5 microseconds.
Stick to making it easy to read is my advice. If you can't afford the occasional call/return you can't afford to have interrupts fire either.
Besides, without seeing the code, there may be other optimizations you are overlooking. Just as an example, using byte instead of int for loop counters that don't exceed 255.
Hi,
Are call and return only 4 cycles each ? I would have thought that more cycles are required for pushing and popping the stack ?
Duane B
CALL and RET are documented in the datasheet to take 4 cycles each. If you have local variables (ie. auto variables inside the function) there would be a couple more instructions to adjust the stack.
4 cycles sounds about right. A couple to save the current address on the stack, and a couple to change the program counter.
The figure quoted by Coding Badly of 2.5 uS is for all 5 calls. Each call/return would only take 500 nS, so that is hardly a big overhead.
Hi,
I remember reading a post somewhere on the overhead of an ISR and in that case, the overhead was quite high due to saving and restoring 'all' of the registers. Surely any reasonably complex function is likely to overwrite at least a few registers and therefore the compiler should be pushing and popping.
The ISR post suggested that there was a standard prolog and epilogue to calling and ISR which added about 55 cycles if I remember correctly.
Am I missing something, are ISRs fundamentally different in the way that registers are preserved ?
Found it, here is the original post to which I am referring - The overhead of Arduino Interrupts | Bill Grundmann's Blog
Duane B