• Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 192 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.

modifying data page pointer during runtime

MattLipsey
Genius 3575 points

I was wondering if any of the Ti types could provide more information on the "position independent data" section 7.1.7 of spru187o, page 154.  I have an image processing routine that has a "wandering" access pattern and is slow as a dog even though I have gone to great lengths to keep all data in L1D SRAM.  I think that having to do far accesses out of order is really slowing things down.  Reading this section I get the idea that I could do a temporary data pointer switch and treat this (large) array as near.   I am willing to build whatever walls are necessary around this routine because it has to go faster, and if I can shave a cycle or 2 off every memory access I would be thrilled.  Any suggestions for how to go about this, specifically how to change the DP from C and how to tell the linker & compiler what I'm doing?

  • TI__Mastermind 41665 points

    This is a good question, though unfortunately I do not have a good answer, my understanding of section 8.1.7 is that you do not directly control when the compiler uses position independent data, it just discusses when the compiler uses position independent data which appears to be limited to the .bss section where it is automatically moving the DP through the .bss section in the three bulleted cases in section 8.1.7. To do what you are suggesting I believe you would either have a seperate C environment (another executable) or a hand written assembly function that operates outside of the current C environment, but the issue even here would be that if you are working on image processing it is likely that none of your data is in the .bss section as it would all be on the heap from malloc calls. Perhaps someone else whom has done more work in optimizing these sort of accesses can comment, I may have to look into this one tomorrow.