|
Giovanni-- There is an excellent TI manual called assembly language users guide(spru186n.pdf) which has a few section on linker,coff sections etc...you shd find that a good place to start. And in general to get strength in system software,like Common Object File Format, linker etc... you can refer to : Computer Systems--A Programmer Perspective by Randy 'O Brian.Its an excellent, excellent book. I could write an ode to it.But I will not.Instead, this mail. --Bhooshan On Wed, 23 Feb 2005 13:51:32 -0800, Giovanni <> wrote: > > > Hello everybody, this post is a bit OT... I'm using CCS to develop some > applications, but sometimes I have some problem understanding the cmd > file. I'm not an expert of what happens at link time, so I would like to > read something about this argument. Is there a good book that explains > the structure of the differents sections in link file? > Thanks a lot Giovanni > > -- ------------------------------- "I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times I've been trusted to take the game winning shot and missed. I've failed over and over again in my life. And that is why I succeed." -- Michael Jordan -------------------------------- |
Re: doubts about linker
Started by ●February 23, 2005
Reply by ●February 23, 20052005-02-23
|
Hello everybody, this post is a bit OT... I'm using CCS to develop some applications, but sometimes I have some problem understanding the cmd file. I'm not an expert of what happens at link time, so I would like to read something about this argument. Is there a good book that explains the structure of the differents sections in link file? Thanks a lot Giovanni |
Reply by ●February 24, 20052005-02-24
|
Hello Gio,
This can be a confusing topic. I believe that what you are asking
about is officially called the 'linker command file' [has
'.cmd' extension].
From looking at some of the CCS projects, you can see the extremes.
Non-DSP/BIOS projects usually have a very simple linker command file
[LCF]. Projects that use DSP/BIOS have a very long and complicated
LCF.
I am no expert on LCF, but I have created a few.
My simple overview is that-
1. any memory that you want the linker to know about should be
defined by the 'memory' directive.
2. you can divide the memory into as many or as few named regions as
you want [within reason]
3. the 'sections' directive [??] maps portions of your code to
specific named memory regions defined by the memory directive
...and then it starts getting complicated [or tedious].
Refer to
TMS320C6000 Assembly Language Tools Users Guide [spru186]
mikedunn
Giovanni <g...@yahoo.it> wrote:
|
Reply by ●February 24, 20052005-02-24
|
Everyone-- I thought I would resist myself from an *attempt* at a discourse but Mike has got me going again...Thanks! I Know that there is a strong temptation to view linker as just a necessity rather than as a powerful,tweak tool for big boys. While this attitude will not hurt your development work in general , in fact this approach of a *flat memory model* (AKA not using a LCF file at all) will work very well till you design your application and get it working in a general sense but NO further than that in terms of optimizing precisely for a bootable device. In my experience, you have to *dirty your hands* in atleast three of the following situations: 1] My code size and/or data size is larger than 100K but my fast, internal memory is only 64k (or a larger but similar proportion). My external memory is large but if I put all my code(data) in external memory my applicatiosn will not work in real time. Soln: Splitting of sections(code/data). This allows you to distribute the code across the memory hierarchy. 2] I have lots of functions--Func1,Func2,Func3... in my code but all of them wont run at the same time--in fact some some of them may be call ed only once. But due to the default nature of the linking algorithm all of them end up settling down inside my .text and .text becomes too huge(So huge that it may not even fit inside internal memory!) even though the *effective operating code* size is much less. Soln: Implenting Overlays or Run Time Relocation. This is to allocate a small piece of fast internal memory among the multiple, *lots of functions* during run time, but *load* all of them into a large slow memory 3] I was told to implement my functions to be Re-entrant-- what ever that means-- and to utilize scratch memory(and not use any hard coded address ever) to secure eXpress DSP compliancy--what ever that means-- for my company's algorithm's. Soln: XDAIS standards. Am sure there are more situations then this when you might have to get hands on with the linker,but these three are my exposure. And I also realise for ee grads sometimes this whole thing can seem like voodoo, but I promise you if you read the non-existent manuals from TI, you would be fine! Finally, Linker is all about *exploiting* your target's memory hirerarchy (In no system will you ever be blessed with non-hierarchical model) --Bhooshan On Wed, 23 Feb 2005 21:10:11 -0800 (PST), Mike Dunn <> wrote: > Hello Gio, > > This can be a confusing topic. I believe that what you are asking about is > officially called the 'linker command file' [has '.cmd' extension]. > > From looking at some of the CCS projects, you can see the extremes. > Non-DSP/BIOS projects usually have a very simple linker command file [LCF]. > Projects that use DSP/BIOS have a very long and complicated LCF. > > I am no expert on LCF, but I have created a few. > My simple overview is that- > 1. any memory that you want the linker to know about should be defined by > the 'memory' directive. > 2. you can divide the memory into as many or as few named regions as you > want [within reason] > 3. the 'sections' directive [??] maps portions of your code to specific > named memory regions defined by the memory directive > ...and then it starts getting complicated [or tedious]. > > Refer to > TMS320C6000 Assembly Language Tools User's Guide [spru186] > > mikedunn > > Giovanni <> wrote: > Hello everybody, this post is a bit OT... I'm using CCS to develop some > applications, but sometimes I have some problem understanding the cmd > file. I'm not an expert of what happens at link time, so I would like to > read something about this argument. Is there a good book that explains > the structure of the differents sections in link file? > Thanks a lot Giovanni |
Reply by ●February 24, 20052005-02-24
|
Thanks a lot to everybody, I found the documents that you proposed. They will be very useful. Thanks again Giovanni Giovanni wrote: >Hello everybody, this post is a bit OT... I'm using CCS to develop some >applications, but sometimes I have some problem understanding the cmd >file. I'm not an expert of what happens at link time, so I would like to >read something about this argument. Is there a good book that explains >the structure of the differents sections in link file? >Thanks a lot Giovanni |
Reply by ●February 24, 20052005-02-24
|
In fact in the last months I realizad some program that use cache and DMA, but when I implemented it very often I had to try and correct the settings inside the cmd file. So now I decided to use a different approach, and to try to understand what I'm doing. Your tips will be very useful Thanks a lot Bhooshan Iyer wrote: >Everyone-- > >I thought I would resist myself from an *attempt* at a discourse but >Mike has got me going again...Thanks! > >I Know that there is a strong temptation to view linker as just a >necessity rather than as a powerful,tweak tool for big boys. While >this attitude will not hurt your development work in general , in fact >this approach of a *flat memory model* (AKA not using a LCF file at >all) will work very well till you design your application and get it >working in a general sense but NO further than that in terms of >optimizing precisely for a bootable device. In my experience, you have >to *dirty your hands* in atleast three of the following situations: > >1] My code size and/or data size is larger than 100K but my fast, >internal memory is only 64k (or a larger but similar proportion). My >external memory is large but if I put all my code(data) in external >memory my applicatiosn will not work in real time. > >Soln: Splitting of sections(code/data). This allows you to distribute >the code across the memory hierarchy. > >2] I have lots of functions--Func1,Func2,Func3... in my code but all >of them wont run at the same time--in fact some some of them may be >call ed only once. But due to the default nature of the linking >algorithm all of them end up settling down inside my .text and .text >becomes too huge(So huge that it may not even fit inside internal >memory!) even though the *effective operating code* size is much less. > >Soln: Implenting Overlays or Run Time Relocation. This is to allocate >a small piece of fast internal memory among the multiple, *lots of >functions* during run time, but *load* all of them into a large slow >memory > >3] I was told to implement my functions to be Re-entrant-- what ever >that means-- and to utilize scratch memory(and not use any hard coded >address ever) to secure eXpress DSP compliancy--what ever that means-- >for my company's algorithm's. > >Soln: XDAIS standards. > >Am sure there are more situations then this when you might have to get >hands on with the linker,but these three are my exposure. And I also >realise for ee grads sometimes this whole thing can seem like voodoo, >but I promise you if you read the non-existent manuals from TI, you >would be fine! > >Finally, Linker is all about *exploiting* your target's memory >hirerarchy (In no system will you ever be blessed with >non-hierarchical model) > >--Bhooshan >On Wed, 23 Feb 2005 21:10:11 -0800 (PST), Mike Dunn ><> wrote: >>Hello Gio, >> >>This can be a confusing topic. I believe that what you are asking about is >>officially called the 'linker command file' [has '.cmd' extension]. >> >>From looking at some of the CCS projects, you can see the extremes. >>Non-DSP/BIOS projects usually have a very simple linker command file [LCF]. >>Projects that use DSP/BIOS have a very long and complicated LCF. >> >>I am no expert on LCF, but I have created a few. >>My simple overview is that- >>1. any memory that you want the linker to know about should be defined by >>the 'memory' directive. >>2. you can divide the memory into as many or as few named regions as you >>want [within reason] >>3. the 'sections' directive [??] maps portions of your code to specific >>named memory regions defined by the memory directive >>...and then it starts getting complicated [or tedious]. >> >>Refer to >>TMS320C6000 Assembly Language Tools User's Guide [spru186] >> >>mikedunn >> >>Giovanni <> wrote: >> >> >>Hello everybody, this post is a bit OT... I'm using CCS to develop some >>applications, but sometimes I have some problem understanding the cmd >>file. I'm not an expert of what happens at link time, so I would like to >>read something about this argument. Is there a good book that explains >>the structure of the differents sections in link file? >>Thanks a lot Giovanni >> >> >> > > |
