I thought (perhaps erroniously) that if variables were declared inside of the main loop, the processor would have to set aside time ot check that they really exist, and then do the same for any operations you require of it.
I would have thought that the logical way past this problem was to declare the variables globally - that way, the location of the variable need only be checked when any calculation is performed.
Am I way off the mark, or would it benefit performance to declare them globally instead of locally?
the processor would have to set aside time ot check that they really exist
A variable is a way for you, when you are writing the code, to refer to a memory location, without having to know specifically which memory address would be used to hold the data when the program is running.
At run time, the memory location exists. There is no checking to see that it exists.
Global variables are assigned memory addresses the same as local variables. When a particular memory location is no longer needed depends on the scope of the variable, but when it is no longer needed, it doesn't go away.
The assembly code created from the c/c++ code in the sketch is extractable from one of the intermediate files that the compiler produces. If you are interested, there is a command, avrdump I think, that can do this. Take a look at the extracted assembly code. You'll see that there is no checking for memory being allocated, and no allocation performed.
Global variables are assigned memory addresses the same as local variables
Is that the case on the AVR?
Usually in C, local variables are assigned memory addresses relative to the current stack frame, whereas globals are assigned fixed memory addresses.
Usually in C, local variables are assigned memory addresses relative to the current stack frame, whereas globals are assigned fixed memory addresses.
I believe that you are right. I was trying not to get too detailed, though. The linker resolves everything so that variables refer to an address in memory. Coders don't have to worry about how it's done, and I don't believe that it affects run time performance to use local variables.
If local variables are allocated on the stack, they may be somewhat slower to access than if they were global variables (its very close, though.) On the other hand, local variables may also end up optimized into registers, in which case they are much quicker than global variables.
(Since the AVR is a register oriented machine, variables pretty much need to be moved into registers before you can do anything with then anyway.)
In any case, I don't think that the performance of local vs global variables is likely to be "a problem"; this is one of those "optimizations" that you really shouldn't do unless you find that your code is too slow for some reason. Define variables in the scope that makes sense, rather than trying to second guess which type will give you irrelevant extra performance.
I don't believe that it affects run time performance to use local variables.
I believe (on little "evidence"!) that few Arduino programs will behave badly because of run time stolen to deal with handling local variables. And there's good news on that front which I will come to in a moment.
On the other hand, I would bet serious money that extensive use of global variables will lead to many, many hours being wasted by programmers doing code debugging! Or to limitations on the scale of program that can be written before things become Just Too Much to take further.
Local variables are a seriously useful "medicine" to apply to programs to keep them bug free.
And the good news: If you DO write something that is very time critical, and after it is mostly working you want to CAREFULLY replace some local variables with globals... that can still be done!
I'm coming from C++ where usage of global variables is a sin, except for people that used to work in C before. These are usually the people that reject every invention from past the 90's. Because of that I always though globals to be common practice in C and especially restricted environments.
I'm glad to hear, that also when programming microprocessors, people care about bug-free, maintainable programs.
In C++ the premise is that the scope of a variable should be as local as possible, and that it shall have a well defined state during all of it's lifetime.
With C++ on 32bit Windows we could even measure that local variables declared inside a loop can be faster than variables declared before the loop that have not-so-well-defined state before and after the loop. Modern optimizers are amazing. And since avr-gcc is gcc, I would assume the optimizer to be very good for the Arduino as well.
Sadly, I think you may be right about the rampant use of global variables in C programs.
However, good C programmers have always minimized the use of globals. (Old Fortran joke: why did the main routine and the subroutine have so many argument? Because they had nothing in COMMON.)
You don't need classes to organize your program as if were OO. You can create modules that have all of their data as static within the module, and only manipulate that data through functions within the module. Of course, you don't get easy inheritance and polymorphism, but you also don't get all of the baggage that comes with C++.
The bottom line is that programmers can use any language to write correct, easily-understandable programs, and programmers can use any language to write pure dreck.
Thanks a lot! I'll be looking into that in my spare time. The main thing for now is the guilt-free use of variables in the main loop.