Hello. Is there any way to simplify the call tree manipulation in linker..? (Scripting kind of) My code has number of function calls through pointers. The functions are divided in few main groups. I want to achieve overlay among the functions of an individual group.(Intragroup) At the same time I want to avoid overlaying among the functions from different groups.(Intergroup) Adding and removing the references for every function from every other function is big task. I somehow managed it at the moment. However it is not good practice from the long term perspective.
So, can I define a list of functions which can be used at multiple places in linker script. Or can I share a macro from compiler to the linker..?
Best regards, Vivek.
Have you read the Application Notes and knowledgebase articles about using function pointers in C51?
They will point you to the Linker Controls for manipulating the call tree...
A forum search would also be a good idea...
But is it really worth it? Would not the effort be better spent in designing for an architecture where all this stuff is just not an issue?!
Hello Neil, Thanks for ur help.
I hope u r talking about the keyword overlay(!/~) when u r saying linker control.
What I am looking for is the way to group a list of functions to avoid redundancy in linker file. Because otherwise every function and its reference with others leads to numerous combinations. Ultimately same function would be specified at least 10 times in my case.
I am not able to find any such way in the tool manual. So please let me know if there is any way of doing what I just mentioned.
Best regards, Vivek
Sorry, I forgot to mention. Redesigning architecture is not an option. My system requirements will always result in multiple function calls through pointers. No matter how I design it. Besides, changing design architecture for tool set...mmm...sounds strange. Expecting from tool set an easy way to manipulate the call tree, sounds more obvious and practical. What do you think..? So please let me know if there is any way to group the functions in linker; Or I have to live with the situation..?
Thanks for your help.
Here the method to manager this kind of stuff is to use scripts/apps to analyze the source and linker outputs (.MAP, .OBJ, .LIB, etc) and automate tasks which the computers were designed for. The output from such a process might include make files, and auto-generated source files, along with call tree and working set analysis.
Hey.
You shud go to my forum.
the site its got loads of cool information about the 51 and a huge community of real talented professionals.
check the stats. its real big and growing.
just use the search bar and ask the question. some of the search engine is controlled by a matrix of 51s.
"My system requirements will always (sic?) result in multiple function calls through pointers"
Really?
When I looked at this, I concluded that the chances of getting manual calltree manipulation all correct - and maintaining it that way - were slim. So I redesigned the code to not use function pointers. It wasn't hard.
But, if you really must use function pointers, have you studied the app note - it shows you how it can be done without having to manipulate the calltree.
You do realise, don't you, that this is all due to a fundamental limitation of the 8051 hardware architecture - so, if function pointers really are so essential to you, you have really chosen the wrong target architcture!
"Expecting from tool set an easy way to manipulate the call tree, sounds more obvious and practical"
Well, there's only so far you can bend an inappropriate architecture...
You can sometimes get away with using a hammer to drive screws - but expecting hammer makers to adjust their designs to better drive screws is solving the wrong problem...
Redesigning architecture is not an option. My system requirements will always result in multiple function calls through pointers. I'm calling BS on that assessment.
Function pointes are often the most obvious and convenient way to express a design. But they're never actually necessary. Every call through a function pointer can instead be expressed by a switch() construct calling one of the applicable functions in question, if need be.
No matter how I design it. Then maybe you need to learn more about either a) design techniques suitable for smallish controllers, or b) picking the right class of controller for the job.
Hey dude.
Why don't you admit you don't know what your talking about?
Just do it properly.
H Burger MSt
>> a huge community of real talented professionals
If my experience with forums counts for much I'd expect several orders of magnitude more members fall into the talentless pool.
I can't fail to admire a forum so professional that the person boasting it's virtues finds it unnecessary to mention the name of that forum.
Hello, I am not expecting linker to automatically manipulate the call tree for me. I know it has to be done manually. Now, if you may have overlooked my question, is there any way to group the function names in linker file..?
Calling functions through pointers. My system has several modules which are plug able kind of. Just to reuse flash area. So pointers can not be avoided. Besides, this is an evolved product running in the market. So changing everything for tool set and testing it again calls for too much efforts and risk.
Now I would really appreciate if someone answers my basic question is there any way to group the function names in linker file..? instead of wasting time in suggesting changing the design.
Best regards, Vivek.!
Now, if you may have overlooked my question, We didn't. We just concluded you were asking the wrong question.
My system has several modules which are plug able kind of. Just to reuse flash area.
So not only did you pick (and stick with) the wrong CPU architecture for the job, causing a need to jump through hoops to cram all the code into the available address space; you even picked the wrong set of hoops to jump through, rolling your own "plug-in, kind of" system instead of using the existing code-banking mechanism.
So pointers can not be avoided. Repeating that claim doesn't make it any less incorrect.
So changing everything for tool set and testing it again calls for too much efforts and risk. Nobody asked you to change everything. But you apparently believe so strictly that nothing you did so far could possibly have been a mistake, that you won't even consider changing anything. Good luck with that attitude in the future. You (and your customers) will need it.
My system requirements will always result in multiple function calls through pointers. No matter how I design it. that reminds me of a fatty Italian sausage. If you can't design without function pointers, you are not a designer but a coder
The nice thing with software development is that there are often an almost infinite number of ways a problem can be solved. And often, quite a lot of solutions will work well.
But when it comes to the 8051 architecture, quite a number of solutions that could work well on other processors will suddenly become sub-standard - the 8051 is not a processor designed for general support of high-level languages.
Without a general stack functionality and pointer functionality, there is only so much you can do when trying to get the processor to support the C language.
The good thing about C, is that a well designed program can often be moved to other hardware architectures with a reasonable amount of work. And it's often meaningful to regularly reevaluate used hardware components of existing products, since most products are in need of constant cost reductions. Or in need of adaptability to changing market requirements.
Being stubbord with continued reuse of old hardware designs or software designs is seldom a good way to protect the market shares or to fight for new market segments. It takes investments to push forward - standing still and trying to defend current positions is just an example of stagnation. The competition will not stand still, but will look at improving their products to overrun such a defence.
Yet another poor attempt of blaming anything possible. Why is this so difficult to accept the fact that there is no way one can combine function names in linker file..? Anyways. I already concluded and even started developing perl script for that.
About attitude. The answer expected to my question was very simple. Either yes or no. Which by the way is yet not said by the professional experts here. Instead the hardware architecture, the software design and even function pointers (lol) are blamed. So just rethink. Who should improve on attitude front..? The person seeking for help for using your tool Or the person who is so uncomfortable in accepting the fact.
By the way, the plugin system I mentioned was not to overcome the addressing limit. I m already using banking technique for that. The plugin system is to literally download a new piece of code and registering its entry in a look up table. Now please don't suggest me that I should have fixed calling locations for new functions instead of using function pointers.
Not directly but I got the answer from this forum. Thanks a lot.