This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi
I am working with TMS320DM642 DSP, with DSP BIOS 5.31.02
I am trying to migrate with my code from CCS 3.3 running on Windows XP to CCS v5.3 running on Window 7 64 bit , and stay with the old version of code generation tools CGT v6.0.18.
I succeed to compile my project , and I see that the all compilation and linker flags are ok . But my code behaves different from original version compiled on ccs 3.3.
Its seems like the optimization , does not work,. the code runs much slower than original version.
There is some known problem with using the old code generation tools (CGT v6.0.18) with CCS5.3 running on Window 7 64 bit ?
Thanks
Hello,
Did you import the old project into 5.3 or did you create a new project?
Genady Kagan said:There is some known problem with using the old code generation tools (CGT v6.0.18) with CCS5.3 running on Window 7 64 bit ?
That version should be fine with 5.3.
Genady Kagan said:But my code behaves different from original version compiled on ccs 3.3.
Its seems like the optimization , does not work,. the code runs much slower than original version.
Please provide some more details on how you came to this conclusion.
Thanks
ki
Now its start working ..i notice , that its depends on linkage order , that chaged with chossing different "Builder type"
I change the “Builder type” from external (with settings CCS_BUILD_UTILS/gmake) to internal , and this case to different linkage order . For example , my *.cmd files , when the “Builder type” was external , the cmd files, was linked last , after all objects. When the “Builder type” was external , the cmd file was first in the linkage order .
Can you explain please , what the difference between “internal” and external “Builder type” , and why the linkage order is important? Probably I have some bug in my code .., that the different linkage order prevent memory corruption .
Thanks
Genady Kagan said:Can you explain please , what the difference between “internal” and external “Builder type”
internal builder will use CDT's built in functionality to built projects. The external builder will allow an external utility (like gmake) to be used. You should always be using the external builder option for CCS projects
Genady Kagan said:and why the linkage order is important?
This is more of a general question and there is a lot of information regarding link order:
http://chrisoldwood.blogspot.com/2012/09/from-visual-c-to-gcc-linker-order.html
In any case, you can specify the link order regardless of the builder type. There is a tab called 'Link Order' under the 'Build' or 'CCS Build' (depending on if you show advanced settings) where you can do this.
Thanks
ki
Hi
Thanks for reply
The only difference between link order with external and internal builder, that the place of the cmd file, that is generated from TCF file automatically
The internal builder puts this cmd file last , in link order
The external builder puts this cmd file first in link order
I did not see any more difference .
May be , you have idea , why it important ?
Please do not use the internal builder. Use the default external builder.
You can still control the link order manually when using the external builder
The order of when things are linked can have a great impact. Please refer to the url I mentioned for more details.
Thanks
ki
Hi I found the problem ! In EMAC driver from NDK and CSL library , was object with the same name , I need the object from the NDK and not from CSL .When I change the link order between two libraries, everything start working. Thanks
Yep, that makes sense. That is why the link order is important. The linker will use the first one it finds. Hence it is important to have that the correct one first in the order.
Can I prevent such kind of bugs , with some compiler /linker settings ? I think , that another linkers , Visual studio for example , alert me , if I have to objects for linker with the same name .