By default RC51 compiles in NOAUTO mode, meaning that local variables are allocated in shared static banks which are allocated to prevent sharing between procedures that are active simultaneously. The alternative is AUTO, where local variables are allocated on the stack, which on my uPSD3434 is a pretty small space.

The problem with int putchar( int)

If I supply my own version of putchar in order to use stdio routines (printf etc) with an LCD display, the compiler does not know that (say) main calls puts(char*) calls putchar( int) and so allocates the same pseudo-static memory for main's variables and those of putchar and its subroutines, resulting in main's locals becoming corrupted whenever it prints.

The only solution I can find is to ensure that my LCD driver declares no pseudo-static local variables, either by making all variables static and/or global or compiling everything EXCEPT the putchar entry point automatic and reentrant (see below). I can't declare putchar itself reentrant because its call is pre-compiled in the library and is of the pseudo-static type, so I have to ensure it will declare no local variables, whatever compiler switches I might later set.

The problem with interrupts and subroutines

A similar problem arises with interrupts. The interrupt service routine itself is implicitly automatic even under NOAUTO but any subroutine it calls, and any sub-subroutines need to be declared automatic (either compiled AUTO or declared reentrant) because the compiler does not recognise that their local variables must be kept in a space dedicated to that particular interrupt vector.

The problems with mixing AUTO and NOAUTO

If different parts of a program are compiled with different settings of the AUTO switch in an attempt to solve some of the above, further problems arise because the procedures use different parameter passing protocols, and the compiler does not detect how their targets were compiled. The internal (object file) names of procedures compiled with the reentrant keyword are marked so that they will be called correctly or will not link, but those simply compiled under AUTO are not, even though they generate the same code. And even if they were, global procedures would still have to be declared reentrant in the shared header file so that the compiler would know which call to generate.

If parameters are passed on local variables, either because there are too many parameters or because the NOAREGS switch is in force, then the calling procedure has to know where the local variables will be kept. This can only be done by either ensuring that all were compiled with the same setting of the AUTO switch, or that all automatic procedures with parameters that will be called from pseudo-static procedures are also declared reentrant. (As far as I know there is no way of calling a pseudo-static procedure with parameters from within an automatic one.)

Any thoughts or comments? Am I missing something? The implications seem to be quite restrictive on coding techniques for larger applications and shared code. It seems to me that the bank naming for pseudo-static variables needs to be a bit more clever to identify putchar etc. as a special case, and to separate out spaces for interrupt vectors. Or else these limitations need documenting.

Tim Jackson