re-entrant code

You have to realize that when talking about global variables, the problem is more about architecture than the used code-generating tool.

Most architectures can read an 8-bit variable atomically. But can they read a 16-bit, 32-bit or 64-bit variable atomically?

Some architectures can increment a memory variable atomically, while other architectures may need a load + increment + store. If the variable is too large to increment directly, then the code-generating tool (any tool - or yourself, using assembler) will have to care about overflow rippling to the upper parts of the variable - for example by adding extra add-with-carry steps.

You have to realize that when talking about global variables, the problem is more about architecture than the used code-generating tool.

Most architectures can read an 8-bit variable atomically. But can they read a 16-bit, 32-bit or 64-bit variable atomically?

Some architectures can increment a memory variable atomically, while other architectures may need a load + increment + store. If the variable is too large to increment directly, then the code-generating tool (any tool - or yourself, using assembler) will have to care about overflow rippling to the upper parts of the variable - for example by adding extra add-with-carry steps.

To make Per happy:
This relates to the '51
Since the OP started the thread with C51 I have changed MCU back to the C51 to stay with the OPs intent.

I have never used reentrant code. Yes, I have had cases where it might have been desirable (e.g. a function shared by an ISR and main) but the potential debugging nightmare has kept me from using reentrant code.

I think the OPs worry that he 'might' have reentranr code is greatly overblown. Just make sure that all functions called from ISRs (if you absolutely have to have them) have names that are e.g. ISR..... and no ISR.... function is called from main.

Erik

PS the one '51 case I can see for reentrant code would be to 'core use squeeze' a unit that was to be made in millions.