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
So, let's see: Your code is too big to fit into the 64K code size limit of the 8051 architecture, so you've gone to code banking. Now, your code is too big to fit within the limitations of code banking! Don't you think it might be time to reconsider the appropriateness of an 8051 to this particular project...? At least, take a look at some of the 8051s with extended address space...
It would be valuable to have a tool that can analyze the source for locality of reference, and optimize the bank assignments accordingly. Currently, this process must be done purely manually. For example, let's say I have modules C, S1, S2, T1, and T2. It just so happens that S1 calls a lot of stuff in S2, and vice versa, but not much of anything from T1/T2. Conversely, T1/T2 are tightly bound to each other, but have little to do with S1/S2. Everybody uses module C. The ideal bank assignment here will be C in the common bank, S1/S2 in bank 1, and T1/T2 in bank 2. If you move things around, then extra stubs get generated in the common bank to call all the extra functions. This can be a significant amount of space. 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.
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.
View all questions in Keil forum