5.7.2.2.1 Register-optimized Reentrant Stack

Accessing objects on the software stack and via the stack pointer requires more code than accessing objects on the compiled stack, so despite offering reentrancy, using the software stack comes at a cost. To allow both reentrancy and efficient access, the compiler can choose to place objects nominated for the software stack into special working registers that are dynamically allocated from a pool of fixed memory locations. Since these registers can be directly accessed without the need of a stack pointer, they permit efficient code, but unlike objects in the compiled-stack, they are saved and restored as required by interrupt context switch code, just like hardware registers, thus allowing reentrancy.

When generating code for reentrant functions, the compiler will consider using the register-optimized reentrant stack if this feature has not been disabled by the -fno-rors option (see Rors Option). Note, however, that some eligible objects might still be allocated space on the software stack, even when this feature is enabled.

The number of dynamic working registers available will vary with the selected target device and whether the reentrant or hybrid stack model has been chosen for the program. The device's common (unbanked) memory is prioritized for allocation of working registers to reduce the bank-switching overhead. When building for Enhanced Mid-range devices and common memory is insufficient, additional general-purpose banked memory might be allocated. If all dynamic working registers have been allocated, objects will be placed in the conventional software stack memory. Thus, it is possible that some stack-based objects defined by a program might be in working registers and others in conventional software stack memory. It might even be possible that stack-based objects from one function are also stored using both forms of storage. Since the allocation can vary from build to build, you should not make assumptions as to where these objects are located.

The working registers allocated for a project have C domain names such as __BTEMP_COM and on Enhanced Mid-range devices, such as __BTEMP_BLK0 and __BTEMP_BLK1 etc., and in the assembly domain, they will appear with symbols such as btemp, btemp1, btemp2 etc. (you might also see concatenations of these registers, such as wtemp and ltemp etc.). These working registers are, hence, sometimes called btemp variables or btemp registers.