Keil Logo

Theory of Operation

Classic 8051 devices support only 64 KBytes of code or program space. However, with code banking an application could support multiple banks of 64K and simply switch between them as the need arises. The most obvious hardware requirement for this is additional address lines (which may connect to an on-chip I/O port or an external memory-mapped latch).

Code banking programs support multiple banks of ROMs or program code. When your program calls a function in the current bank (an intra-bank call) it simply jumps to that function's physical address. To call a function in a different bank (an inter-bank call), your program must first switch to that code bank and then jump to the function's address.

The tricky part is how to switch banks and seamlessly continue execution without landing in the middle of the wrong code in the right bank. For example, when calling a function in Bank A from a function in Bank B how does the program switch code banks and ensure that code in the new bank is aligned with the bank switching code in the first bank? When the program takes-off from one bank it needs a landing-zone in the target code bank.

That problem is solved by the linker and requires an area of code space that is common to all code banks. This Common Area contains all the code that is required to switch from one code bank to another and to call a function in one bank from a function in another bank. This is known as the inter-bank call table and it takes care of all take-off and landing-zone issues.

Another problem is how reset and interrupt vectors are handled. Typically, interrupts require fast execution and low latency. Code banking interrupt service routines is not desired. So, they are located in the common area. Basically, anything that must always be available without a bank switch must reside in the common area.

Indirectly-called functions (those invoked via a function pointer) pose a special problem since the function may be located in the common area or in a code bank. It is impossible to determine at compile time what function a pointer references. By default the linker creates an inter-bank table entry for indirectly-accessed functions. The NOINDIRECTCALL directive may be used to inhibit this feature.

All remaining program code may be located either in the Common Area or in a Code Bank. There are, of course, performance criteria that may dictate where a particular function resides.

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.