will using functions add to memory ?

[Mechatrommer]

Put static in front of it , and remember to pre declare it in the top.
And maybe even tell avrgcc to inline the function.
static inline uint8_t myfunc(void);   //predeclare

It's generally better to leave the decision on whether or not to inline the function up to the compiler. Unless maybe the function is used in a really tight loop or an ISR.

Bingo.  Compilers generally do a much better job of optimizing code than programmers do.

inline (or static) is just like the rest of keywords in C, you use it when you need it, or you use it when you know what you are doing. i will call a compiler a stupid compiler if i put the word "inline" when with its infinite wisdom of stupidity opts not to inline it.

[andersm]

Declaring a function as static doesn't tell the compiler that it's used only once and therefore can be inlined.

Of course it doesn't, but if the compiler has to generate an outline copy it is less likely to inline it, unless it's trivial.

[Jeroen3]

Relying on the compiler to make code fast is bad. Since programming languages are designed to be portable you can get issues when you take your modules to another platform.
Also, you want to be able to debug (step through) your code. With -Omax this is almost impossible.
Code should be fast and debuggable. _{(is that a word?)}

Best thing to do is make everything as explicit as possible and leave the implicit behavior to a minimum. If you intend to use a functions as inline, don't rely on the compilers -O flags, but use the proper keywords. This way it is obvious to any reader reading the code while not having to read any assembler or mapping output. And most of all, resistant to compiler updates.

Sure you will use some of the compilers optimization, otherwise C would translate awful. But inline, static or const should hint the compiler on what you are trying to achieve.

[amyk]

rather than introduce/support instructions for zero overhead looping.

x86 has had LOOP/LOOPNZ(E) since the beginning, Intel currently doesn't optimise it but it's there and in the future maybe they'll make use of it.

[John Coloccia]

Relying on the compiler to make code fast is bad. Since programming languages are designed to be portable you can get issues when you take your modules to another platform.
Also, you want to be able to debug (step through) your code. With -Omax this is almost impossible.
Code should be fast and debuggable. _{(is that a word?)}

Best thing to do is make everything as explicit as possible and leave the implicit behavior to a minimum. If you intend to use a functions as inline, don't rely on the compilers -O flags, but use the proper keywords. This way it is obvious to any reader reading the code while not having to read any assembler or mapping output. And most of all, resistant to compiler updates.

Sure you will use some of the compilers optimization, otherwise C would translate awful. But inline, static or const should hint the compiler on what you are trying to achieve.

This is complete nonsense.  Portability is a strong argument FOR compiler optimization, not against.  Or maybe you'd rather write your program 5 times rather than just recompile it 5 times?

As far as stepping through with a debugger, this is about as far down on the list of concerns as it can get.  Especially in the embedded world, most of us just pull up our big boy pants and don't use the debugger anyhow.  It's usually easier, faster and certainly for in circuit hardware a lot less trouble to simply use some debug statements....or even just stare at the code for a few seconds.

[macboy]

Will using functions for portions of my code add to the program memory usage (if called once only)? my understanding of functions is that the contents of the function just replaces the function call. so basically assuming i use a function once only will calling the function use more program memory than putting the functions code straight into the program ?

Declare your function as static inline, and then you are assured that the function will not be "called" but that the equivalent code will be put in place of the (and every) function call. If you call your function in only one or two places, this usually reduces code size, increases execution speed, reduces stack usage. If you call it in many places, it can increase code size a lot (or it can actually decrease code size, if the function is very simple).

If you just use inline but not static inline, then the compiler will still generate the inline code where it makes sense to, but will also (likely) generate a callable version of the function for linkage in other files. This increases code size, so you don't call the function from elsewhere, use static.

Inline is tricky; the compiler needs to know the definition (not just declaration) of the function prior to it being called. So the definition must come higher up in the file than the first usage of that function, or the compiler can't inline those earlier calls to it.

[dannyf]

Declaring a function as static doesn't tell the compiler that it's used only once and therefore can be inlined.

Bingo! Absolutely right.

I am still waiting for someone to extern a static type,

[zapta]

Using static for internal functions is a good practice, regardless of inline, it's limits the scope of the fiction. Also inline can be used with non static functions, for example when the function is in a .h file. And last but not least, inline can reduce size also for simple functions that are called multiple times because it eliminate the function call sequence.

Sent from my Nexus 5 using Tapatalk

[HackedFridgeMagnet]

Relying on the compiler to make code fast is bad. Since programming languages are designed to be portable you can get issues when you take your modules to another platform.
Also, you want to be able to debug (step through) your code. With -Omax this is almost impossible.
Code should be fast and debuggable. _{(is that a word?)}

Best thing to do is make everything as explicit as possible and leave the implicit behavior to a minimum. If you intend to use a functions as inline, don't rely on the compilers -O flags, but use the proper keywords. This way it is obvious to any reader reading the code while not having to read any assembler or mapping output. And most of all, resistant to compiler updates.

Sure you will use some of the compilers optimization, otherwise C would translate awful. But inline, static or const should hint the compiler on what you are trying to achieve.

This is complete nonsense.  Portability is a strong argument FOR compiler optimization, not against.  Or maybe you'd rather write your program 5 times rather than just recompile it 5 times?

I am pretty sure you misunderstood him, its not complete nonsense. and hardly a fair analogy.

As far as stepping through with a debugger, this is about as far down on the list of concerns as it can get.  Especially in the embedded world, most of us just pull up our big boy pants and don't use the debugger anyhow.  It's usually easier, faster and certainly for in circuit hardware a lot less trouble to simply use some debug statements....or even just stare at the code for a few seconds.

Some of us (don't know the numbers) like using a debugger in preference to debug statements, I just want to check that those pants of yours aren't so high that they are blocking the view.

[andersm]

Some of us (don't know the numbers) like using a debugger in preference to debug statements, I just want to check that those pants of yours aren't so high that they are blocking the view.

If you have to resort to debugging, you have already lost. Preventative measures, such as unit tests, simulation and code analysis are better than any debugger.

[zapta]

If you have to resort to debugging, you have already lost. Preventative measures, such as unit tests, simulation and code analysis are better than any debugger.

'Lost' is a big word. There is more than one way to skin a cat.

[tjaeger]

Declaring a function as static doesn't tell the compiler that it's used only once and therefore can be inlined.

Bingo! Absolutely right.

I am still waiting for someone to extern a static type,

If a static function is used once in a compilation unit, then the compiler can be sure that it is used only once, so it will inline it even at the most modest of optimization settings.  Why is this so hard to comprehend?

[John Coloccia]

It also allows the compiler to do other optimizations that it would normally not be able to do, both outside and inside the function itself.  Anyhow, it's just good practice not to clutter up the global namespace unless something really is globally needed.

re: debugging and stuff
Common practice...and GOOD practice....is to log just about everything and to have multiple log levels that you can turn on and off....or even compile out of your code entirely.  Yes, it takes upfront work to build such a thing, but once it's built you take it from project to project and just make minor tweaks to be compatible with the various platforms.  Maybe one goes to a serial port...maybe one goes to a file...or to IDE's console.  It's such a pleasure to have a bug come in from 5000 miles away, with the zipped up logs, and to be able to immediately see exactly what the problem is.

On one project, when I was a wee lad programmer, they released the code with debug symbols built in.  I used that trick over and over in my career.  What you do is implement a stack-walker in the global exception handler and using the debug information not only can you log the entire chain of calls, but you can get the exact value of all of your local variables, and you get the exact line numbers the calls were made from, including the exact line number that caused the exception.  Talk about a powerful tool!

Anyhow, that's usually a lot more useful than the typically crappy, command line debugger nonsense that come with so many environments.

[HackedFridgeMagnet]

If you have to resort to debugging, you have already lost.

I think the logic of that statement is flawed.

Preventative measures, such as unit tests, simulation and code analysis are better than any debugger.

I think the logic of that statement is flawed.



I think people who pride themselves on programming should be careful to write arguments that make logical sense. Just putting some qualification around these bald statements sometimes does the trick.

eg.

Code: [Select]

"I have never found a use for a debugger, so I can't understand why anyone would use one".

[andersm]

If you have to resort to debugging, you have already lost.

I think the logic of that statement is flawed.

The cost of fixing an error goes up the more time passes between when it's introduced and when it's discovered. Not introducing bugs in the first place is the cheapest option, which is the goal of methodologies like test-driven development. Simply put, if you're spending a lot of time in the debugger, something is not right.

[Mechatrommer]

narrowmind will think debugging process is just "the debugger" or they probably "lost". anything said which meant to improve code func and flawlessness are debugging processes or techniques. give some thinking of what it takes, how much time needed to unit test a chunk of subroutine, or eyeballing it, analyzing etc anything for that sake. wont we need to debug the unit tester? imho of my 2cnts.

[Jeroen3]

Some bugs, however unlikely, might be caused by flaws in your tools. I've seen it twice already.
Once with ATtiny, which took ages to find since there is no code stepping capability or debug at all.
The entire chip must be considered as black box. You're doomed to follow read the assembler yourself.
And once with Keil, which was easier to solve since you could analyse the compiled code by stepping it, viewing all the registers and find that it translated an if wrong somewhere.

[westfw]

Once with ATtiny, which took ages to find since there is no code stepping capability or debug at all.

You didn't find the simulator useful?  (but OMG, if the simulator has bugs!)

Will using functions for portions of my code add to the program memory usage (if called once only)?

getting back to the original question:  In general, even without any fancy optimizations, the amount of code and RAM use added by using functions vs inline code is small, and the benefits of using functions (in terms of clarity, debugability, modularity, re-usability, and other factors) are relatively large, so that using functions is considered a good practice, even when they are called only once.

[ejeffrey]

If you have to resort to debugging, you have already lost.

I think the logic of that statement is flawed.

The cost of fixing an error goes up the more time passes between when it's introduced and when it's discovered. Not introducing bugs in the first place is the cheapest option, which is the goal of methodologies like test-driven development. Simply put, if you're spending a lot of time in the debugger, something is not right.

When you detect and when you fix a bug has zero relevance to the value of a debugger.  What you mean is that you don't understand debuggers, don't know how to use them, and have never found them valuable.  Which is fine, but saying "You shouldn't use/have to use a debugger" is just parochial nonsense generalizing a tiny bit of your experience to a world you don't understand.