Erik - sure there's ifs and buts for every rule. The examples you give are valid but very specific. With most of the code I've written, these might apply in <1% of the time and when they did apply, I'd most likely use them. If you're writing code that requires execution performance - then you write code from that perspective. Most of my stuff, that isn't the case. My last project spent about 70% of the time in the idle loop! Unless there's a specific case - one can't be too black and white about things so , I at least, tend to generalise.

I may have come across a bit wrong, I am not "fighting" against limiting global variables I use locals extensively. What I am "fighting" against is applying rules learned for the PC (be they valid or not) to the '51. Most "global variables are evil" people carry a pointer to a structure in main() around which makes global variables appear local. That is an example of making the rule more important than the reality. Have a look at the code to fetch and process such a global variable (that seems to follow "the rule") as opposed to the fetch and process of a 'natural' global variable.

as to "requires execution performance" that is the case in virtually all microcontroller apps, that, evidently, many use the '51 microcontroller as a microprocessor should not make microprocessor rules the yardstick for a microcontroller.

Erik

To the "global variables are evil" gang:

If any of you can demonstrate to me that a function 7 levels deep that modify a slot in a struct in main() to which it has been provided a pointer is not working on a global variable I'd like to see that.