On seeing Michael's informative posting on banking using the Keil compiler/linker I thought I should give similar info on what I've found so far with the IAR compiler/linker.

We are using the Philips SAA56xx microcontroller and we can either run out of the internal OTP ROM or from an external FLASH chip (jumper selectable). This chip has the same layout as Michael was describing (native bank switch support in an SFR, 32KB common bank at 0000H-7FFFH, 3 banks visible at 8000H-FFFFH).

The IAR compiler includes an assembly language stub that is easily modified to do the appropriate action to change banks on your particular 8051 derivative. The big differences between the Keil version of bank support and the IAR version is that the IAR has a somewhat lower overhead (each banked "call" is replaced by 7 assembly instructions and each "ret" is replaced by 3 asssembly instructions) but requires the programmer to manage which functions are banked and which aren't.

Basically when the programmer selects the "banked memory model", all functions are considered "banked" unless specifically marked otherwise. For banked functions, the compiler generates the aforementioned 7 instructions (2 moves and a call to a 4 instruction assembly routine) each place that function is called and generates the aforementioned 3 instructions (jump to a 2 instruction assembly routine) at the end of the function in question. If the programmer marks a function as non-banked the compiler will generate normal call's each place the function is called and a normal ret at the end of the function. It is up to the programmer to ensure that all of the caller's of this function are in the common bank or in the same bank as the function being called (so that the bank-switch "call" and "ret" assembly routines don't need to be used). If the programmer messes this up, the microcontroller will happily switch to executing code at the correct address but in the wrong bank, producing unexpected results (not that I've seen this personally or anything :-)

Like the Keil compiler, the whole scheme supports calls to subroutines from COMMON to BANKx, BANKx to COMMON, COMMON to COMMON, BANKx to BANKx, and BANKx to BANKy, but requires the programmer to explicitly control which functions get put in which bank to get the performance benefit of marking some of the functions as non-banked.

I would also second all of Micheal's notes/caveats on banking.

Jeff