A huge function (code size wise) does not have to take a long time to execute. Shared() could be a state machine that handles 50 different states, but each time throught it might only execute a small subsection of the total code.


How can ensuring proper synchronisation be "dangerous"? If you don't properly plan which sections of code can be interrupted and which can't then even REENTRANT on everything will not save you, because these functions are likely manipulating internal state or external hardware which will then get corrupted with REENTRANT or not.


I say: "if a compiler optimisation can cause buggy code to be created, and the only way to prevent this is a detailed manual analysis of the global call tree, then I turn that optimisation off".

If I decided that I wanted to use absolute register addressing, I think I would have to "decorate" every single one of my function names (eg Shared_RB0), and have an automated tool that scans the MAP file to make sure that I didn't call across register banks. Currently this is too much of a PITA for the gain that would be achieved.

Also interestingly I don't believe that Keil library functions (although I rarely use them) can make use of absolute register addressing either, because they don't know which bank is active when they are called.


I don't mean to "single out" Keil, but I have no experience with the other compilers so I can't comment on them. And Keil costs big $$$, so I expect a good result. Keil have (for example) a "global register coloring" optimisation, but yet it can't optimise the simple sequence we are discussing? What's with that?