Structuring Programs

The linker automatically generates an inter-bank call table for all functions that are stored in a code bank and that are called from the common area or from a different code bank. The linker only switches banks when the called function actually lies in a different code bank. This improves function call performance and helps prevent bank switching from significantly impacting application performance. Memory and stack requirements for this technique are considerably smaller than other alternative solutions.

On classic 8051 devices, a bank switch takes approximately 50 CPU cycles and requires two additional bytes in the stack area. Bank switches are relatively fast. Nonetheless, programs should be structured to minimize bank switching.

Programs can, of course, be designed to maximize bank switching. The only penalty for doing so is slower function invocation and poor application performance.

When organizing a program for code banking, you should combine co-dependant routines into each bank. For example, if your application has a run mode and an edit more for setting run-time options, you should attempt to locate all of the run-mode routines in a single bank and all of the edit mode routines in another bank. When the run mode routines call each other, no code banking occurs and the application runs faster.

If you have general-purpose routines that are called from everywhere in your application, locate them in the common area for fastest access. When a function in a code bank calls a function in the common area, no code banking occurs (since the common area is always available).

It may help to remember the following rules:

• Inter-bank calls are slow.
• Intra-bank calls are fast.
• Calls to functions in the Common area are fast.

Note

• Program organization for code banking relies merely on which program modules are located in which code bank. Source code changes are rarely required to obtain optimal code banking performance.