• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 452 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

using linker command file to do L1P cache optimization for dm6437

MattLipsey
Genius 3575 points

I made a small change in my code base and suffered a serious execution time hit, and would like to rule out L1P cache problems as the culprit (and solve them if that is the culprit).  I have over 32kB of source code, but my "critical" section would easily fit in the 32k of L1P cache.  I would like to take a handful of files and have the linker place their outputs sequentially on a 32kB boundary, and just kind of dump the rest of the code after that.  I am using a dm6435 without DSP/BIOS compiled with no debug and -o3 optimization.  What is the best way to accomplish this?

  • 0
    TI__Mastermind 41665 points

    I believe the easiest way to do this would be to use a CODE_SECTION pragma (see section 6.8.1 of SPRU187o) on the function you want placed with a particular alignment, as that would let you put the code in a particular memory section separate from the rest of your code that you could align as you need. I am not sure that this is possible at a file level like you are really asking for, perhaps someone else in the community has done something similar in a different way.

  • 0 in reply to Bernie Thompson TI
    TI__Guru*** 125430 points

    What was the small change you made?  Maybe there's something else at play here.

  • 0 in reply to Brad Griffis
    Genius 3575 points

    I made some minor changes in a few generic functions.  After my initial post, I culled some unused library functions and reduced my code size by about 12k.  This brought my timing results back in line with the original numbers.  I figure there were a few modules close together in size, and slightly increasing the size of one of them caused the linker to change allocation order in ddr2.  L1P cache thrashing seems the most likely culprit to me.  I was familiar with the option Bernie offered, but was hoping to avoid that much manual intervention (and the overhead of 32 byte aligning all the functions, though this might not be that much).