Forums

Re: doubts about linker

Started by Bhooshan Iyer February 23, 2005

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
--------------------------------




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


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:


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<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/c6x/

<*> To unsubscribe from this group, send an email to:
c...@yahoogroups.com

<*




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




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



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
>>
>>
>>
> >