Andy:
I have one advantage. All of the routines that are dispatched via the function pointers are declared void funcname(void) and they have no local variables at all.

I have downloaded, printed, read and re-read all of the function pointer and bankswitch knowledgebase articles from the Keil web site. I think I'm good to go in that regard. There does appear to be just a little bit of a missing link between the idea of "inter-bank" versus "intra-bank" calls when you throw in the concept of the function pointers.

Aside from the local variable overlay analysis that the linker does for functions, (which you avoid for void func(void) types with no local variables, the function pointers themselves are very straightforward. The compiler generates code that loads two registers like R1&R2 with the 16-bit address of the target function and then LCALL's to a little intrinsic code that looks as follows:

Save This Code

MOV DPH,R2
MOV DPH,R1
CLR A
JMP @A+DPTR

This code is all fine. Normally the R2::R1 value is just a code address in the program someplace. In the setup for bank switching the linker sets the addresses for the target of the call into R2::R1 according to the place it thinks the call neeeds to go to. If it thinks the target is in the same bank as the current bank or someplace in the common bank then it simply inserts the target address into R2::R1 in the same way. If the linker correctly recognizes that the target address is in another bank then the R2::R1 value is set to small block of code in the interbank transfer table (which the linker puts in the common bank) and thus the small block of above intrinsic code (also in the common bank!) simply transfers control to the entry in this transfer table. Note that the transfer table is built automatically by the BL51 linker. The code at each entry in the interbank transfer table looks like this:

Save This Code

MOV DPRT,#TRGADDR
AJMP BANKSWITCHER

..where the TGRADDR is the actual function address in the target bank. There is a small subroutine, supplied by the bank switch module which one customized for your hardware setup, that has a pair of small code blocks that switch the bank and the restore it back. The BANKSWITCHER code for a particular bank in my application looks like this:

Save This Code

BANKSWITCHER:
PUSH CURBANK       ;a DATA space variable
MOV A,#1C          ;these make a return
PUSH ACC           ;address on the stack for the UNBANK code
PUSH DPL           ;make DPRT into addr on stack
PUSH DPH
MOV CURBANK,#NEWBANK ;set local var to new bank
MOV BANKREG,#NEWBANK ;set bank select hardware
RET                 ;transfer to target function

From this point the target routine runs. At the time it does its RET instruction it ends up back in the common code in a place to unbank and restore the original bank. This looks like:

Save This Code

MOV CURBANK,#ORIGBANK
MOV BANKREG,#PREVBANK
RET

So you can see that it is really not too complicated. There are a number of machine cycles consumed in the process and so one hopes that the actual size of the called routines is substantial enough so that the bank overhead is a smaller percentage of total CPU overhead to perform the target function.

My problem with this is that the linker is sometimes putting the non-bankswitched path to a subroutine into the call path when it should not be doing this. And unfortunately I don't know how it to stop doing this.

Michael Karas