This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Function pointer with code banking

Hi
I am using Keil compiler for 8051 development.
i use function pointer throught in my program using code banking. i have 512 k of external ROM with 32 k of 16 banks defined.

i went through web and come to know that function pointer can be used with code banking but the condition is that all related files need to be kept in common area or same bank.

and also use OVERLAY.

now i have problem that it is pretty much difficult to keep all related function pointer files in one bank.

i have too many files which gives code overflow if i keep them in same bank.

please reply as soon as possible
and also explore more this OVERLAY with this function pointer and code banking.

regards
Have a nice day
Niraj Patel

Parents
  • It's possible to eyeball the code and get a rough bank assignment by "just knowing" which modules are bound. But it would be much better to have a tool that uses the linkage information to actually calculate the size of the interface between modules, and minimize the inter-bank calls.

    This would suffer from "doing only half the job syndrome". The linker can know the width of the interfaces, i.e. the number of inter-bank code paths, but it can't minimize the inter-bank calls. To do that latter, it'd also have to know how often each of those potential code paths is going to be taken.

    And of course, the OP's program would almost certainly drive any such automatism into complete inefficiency, what with its massive use of function pointers. To the linker, that would tend to look like "everything calls everything". No wonder the trampoline collection grows beyond all bounds.

Reply
  • It's possible to eyeball the code and get a rough bank assignment by "just knowing" which modules are bound. But it would be much better to have a tool that uses the linkage information to actually calculate the size of the interface between modules, and minimize the inter-bank calls.

    This would suffer from "doing only half the job syndrome". The linker can know the width of the interfaces, i.e. the number of inter-bank code paths, but it can't minimize the inter-bank calls. To do that latter, it'd also have to know how often each of those potential code paths is going to be taken.

    And of course, the OP's program would almost certainly drive any such automatism into complete inefficiency, what with its massive use of function pointers. To the linker, that would tend to look like "everything calls everything". No wonder the trampoline collection grows beyond all bounds.

Children
No data