I'm trying to save usage of my Iram memory so I tried to convert
a few unsigned int to unsigned short, and see the change. I was a
bit surprised by the result:
void TASK_Board1ProcessADC(void)
{
static UINT iCounter = 0;
static UINT iCounter2 = 0;
while(1)
{
results in this map:
******************************************************************************
TMS320C6x COFF Linker PC v6.0.8
******************************************************************************
>> Linked Mon May 07 20:39:52 2007
OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out>
ENTRY POINT SYMBOL: "_c_int00" address: 0001c040
MEMORY CONFIGURATION
name origin length used unused
attr fill
---------------------- -------- --------- -------- -------- ----
--------
IRAM 00000000 00030000 0001f102 00010efe RWIX
CACHE_L2 00030000 00010000 00000000 00010000 RWIX
ERAM 80000000 02000000 00030dbc 01fcf244 RWIX
I make one change, from UINT (unsigned int) to USHORT (unsigned short)
as
so:
void TASK_Board1ProcessADC(void)
{
static USHORT iCounter = 0;
static USHORT iCounter2 = 0;
******************************************************************************
TMS320C6x COFF Linker PC v6.0.8
******************************************************************************
>> Linked Mon May 07 20:42:22 2007
OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out>
ENTRY POINT SYMBOL: "_c_int00" address: 0001c060
MEMORY CONFIGURATION
name origin length used unused
attr fill
---------------------- -------- --------- -------- -------- ----
--------
IRAM 00000000 00030000 0001f122 00010ede RWIX
CACHE_L2 00030000 00010000 00000000 00010000 RWIX
ERAM 80000000 02000000 00030db8 01fcf248 RWIX
and rather than my IRAM used going down, it goes up, and while my Eram
goes
down I have a net loss. .far is going to ERAM, and all other compiler
sections
are going to IRAM.
can someone explain why this is happening?
strange memory allocation IRAM vs ERAM, with short vs long.
Started by ●May 7, 2007
Reply by ●May 7, 20072007-05-07
jleslie48 wrote:> I'm trying to save usage of my Iram memory so I tried to convert > a few unsigned int to unsigned short, and see the change. I was a > bit surprised by the result: > > > void TASK_Board1ProcessADC(void) > { > static UINT iCounter = 0; > static UINT iCounter2 = 0; > > while(1) > { > > results in this map: > > ****************************************************************************** > TMS320C6x COFF Linker PC v6.0.8 > ****************************************************************************** >>> Linked Mon May 07 20:39:52 2007 > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > > > MEMORY CONFIGURATION > > name origin length used unused > attr fill > ---------------------- -------- --------- -------- -------- ---- > -------- > IRAM 00000000 00030000 0001f102 00010efe RWIX > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > > > > I make one change, from UINT (unsigned int) to USHORT (unsigned short) > as > so: > void TASK_Board1ProcessADC(void) > { > static USHORT iCounter = 0; > static USHORT iCounter2 = 0; > > > ****************************************************************************** > TMS320C6x COFF Linker PC v6.0.8 > ****************************************************************************** >>> Linked Mon May 07 20:42:22 2007 > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > > > MEMORY CONFIGURATION > > name origin length used unused > attr fill > ---------------------- -------- --------- -------- -------- ---- > -------- > IRAM 00000000 00030000 0001f122 00010ede RWIX > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > ERAM 80000000 02000000 00030db8 01fcf248 RWIX > > > and rather than my IRAM used going down, it goes up, and while my Eram > goes > down I have a net loss. .far is going to ERAM, and all other compiler > sections > are going to IRAM. > > can someone explain why this is happening? >If you make your counters 16-bit variables then I believe the code will sign- or zero- extend the variable which can take additional instruction cycles (and code space). What data model are you using for the C compiler: near, far, or far_aggregate? (The default is far_aggregate.) There is probably an alignment constraint on _c_int00 causing it to jump to the next 32-byte boundary (i.e. the next fetch packet boundary).
Reply by ●May 8, 20072007-05-08
On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote:> jleslie48 wrote: > > I'm trying to save usage of my Iram memory so I tried to convert > > a few unsigned int to unsigned short, and see the change. I was a > > bit surprised by the result: > > > void TASK_Board1ProcessADC(void) > > { > > static UINT iCounter = 0; > > static UINT iCounter2 = 0; > > > while(1) > > { > > > results in this map: > > > ****************************************************************************** > > TMS320C6x COFF Linker PC v6.0.8 > > ****************************************************************************** > >>> Linked Mon May 07 20:39:52 2007 > > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > > ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > > > MEMORY CONFIGURATION > > > name origin length used unused > > attr fill > > ---------------------- -------- --------- -------- -------- ---- > > -------- > > IRAM 00000000 00030000 0001f102 00010efe RWIX > > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > > ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > > > I make one change, from UINT (unsigned int) to USHORT (unsigned short) > > as > > so: > > void TASK_Board1ProcessADC(void) > > { > > static USHORT iCounter = 0; > > static USHORT iCounter2 = 0; > > > ****************************************************************************** > > TMS320C6x COFF Linker PC v6.0.8 > > ****************************************************************************** > >>> Linked Mon May 07 20:42:22 2007 > > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > > ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > > > MEMORY CONFIGURATION > > > name origin length used unused > > attr fill > > ---------------------- -------- --------- -------- -------- ---- > > -------- > > IRAM 00000000 00030000 0001f122 00010ede RWIX > > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > > ERAM 80000000 02000000 00030db8 01fcf248 RWIX > > > and rather than my IRAM used going down, it goes up, and while my Eram > > goes > > down I have a net loss. .far is going to ERAM, and all other compiler > > sections > > are going to IRAM. > > > can someone explain why this is happening? > > If you make your counters 16-bit variables then I believe the code will > sign- or zero- extend the variable which can take additional instruction > cycles (and code space). > > What data model are you using for the C compiler: near, far, or > far_aggregate? (The default is far_aggregate.) > > There is probably an alignment constraint on _c_int00 causing it to jump > to the next 32-byte boundary (i.e. the next fetch packet boundary).memory model is far, that was switched a while ago in the project but I can't remember why. Even if I must have 32 byte (do you mean bit??) boundaries, that still makes no sense as to why my memory usage would INCREASE. I've only changed things to reduce memory usage, if I'm in a partial buffer, then fine no gain, but there still shouldn't be a net increase in memory usage. and if you are correct, what would be the best solution to regain alignment? At worst it should remain the same.
Reply by ●May 8, 20072007-05-08
On May 8, 8:19 am, jleslie48 <j...@jonathanleslie.com> wrote:> On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote: > > > > > jleslie48 wrote: > > > I'm trying to save usage of my Iram memory so I tried to convert > > > a few unsigned int to unsigned short, and see the change. I was a > > > bit surprised by the result: > > > > void TASK_Board1ProcessADC(void) > > > { > > > static UINT iCounter = 0; > > > static UINT iCounter2 = 0; > > > > while(1) > > > { > > > > results in this map: > > > > ****************************************************************************** > > > TMS320C6x COFF Linker PC v6.0.8 > > > ****************************************************************************** > > >>> Linked Mon May 07 20:39:52 2007 > > > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > > > ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > > > > MEMORY CONFIGURATION > > > > name origin length used unused > > > attr fill > > > ---------------------- -------- --------- -------- -------- ---- > > > -------- > > > IRAM 00000000 00030000 0001f102 00010efe RWIX > > > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > > > ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > > > > I make one change, from UINT (unsigned int) to USHORT (unsigned short) > > > as > > > so: > > > void TASK_Board1ProcessADC(void) > > > { > > > static USHORT iCounter = 0; > > > static USHORT iCounter2 = 0; > > > > ****************************************************************************** > > > TMS320C6x COFF Linker PC v6.0.8 > > > ****************************************************************************** > > >>> Linked Mon May 07 20:42:22 2007 > > > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > > > ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > > > > MEMORY CONFIGURATION > > > > name origin length used unused > > > attr fill > > > ---------------------- -------- --------- -------- -------- ---- > > > -------- > > > IRAM 00000000 00030000 0001f122 00010ede RWIX > > > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > > > ERAM 80000000 02000000 00030db8 01fcf248 RWIX > > > > and rather than my IRAM used going down, it goes up, and while my Eram > > > goes > > > down I have a net loss. .far is going to ERAM, and all other compiler > > > sections > > > are going to IRAM. > > > > can someone explain why this is happening? > > > If you make your counters 16-bit variables then I believe the code will > > sign- or zero- extend the variable which can take additional instruction > > cycles (and code space). > > > What data model are you using for the C compiler: near, far, or > > far_aggregate? (The default is far_aggregate.) > > > There is probably an alignment constraint on _c_int00 causing it to jump > > to the next 32-byte boundary (i.e. the next fetch packet boundary). > > memory model is far, that was switched a while ago in the project > but I can't remember why. Even if I must have 32 byte (do you mean > bit??) > boundaries, > that still makes no sense as to why my memory usage would INCREASE. > I've only changed things to reduce memory usage, if I'm in a partial > buffer, > then fine no gain, but there still shouldn't be a net increase in > memory usage. > > and if you are correct, what would be the best solution to regain > alignment? > > At worst it should remain the same.and now that I hooked up my new program to the DSP, I see the counters as 16bit integers (never going above 1000) isn't working. most strange.
Reply by ●May 9, 20072007-05-09
jleslie48 wrote:> On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote: >> jleslie48 wrote: >>> I'm trying to save usage of my Iram memory so I tried to convert >>> a few unsigned int to unsigned short, and see the change. I was a >>> bit surprised by the result: >>> void TASK_Board1ProcessADC(void) >>> { >>> static UINT iCounter = 0; >>> static UINT iCounter2 = 0; >>> while(1) >>> { >>> results in this map: >>> ****************************************************************************** >>> TMS320C6x COFF Linker PC v6.0.8 >>> ****************************************************************************** >>>>> Linked Mon May 07 20:39:52 2007 >>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> >>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 >>> MEMORY CONFIGURATION >>> name origin length used unused >>> attr fill >>> ---------------------- -------- --------- -------- -------- ---- >>> -------- >>> IRAM 00000000 00030000 0001f102 00010efe RWIX >>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX >>> ERAM 80000000 02000000 00030dbc 01fcf244 RWIX >>> I make one change, from UINT (unsigned int) to USHORT (unsigned short) >>> as >>> so: >>> void TASK_Board1ProcessADC(void) >>> { >>> static USHORT iCounter = 0; >>> static USHORT iCounter2 = 0; >>> ****************************************************************************** >>> TMS320C6x COFF Linker PC v6.0.8 >>> ****************************************************************************** >>>>> Linked Mon May 07 20:42:22 2007 >>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> >>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 >>> MEMORY CONFIGURATION >>> name origin length used unused >>> attr fill >>> ---------------------- -------- --------- -------- -------- ---- >>> -------- >>> IRAM 00000000 00030000 0001f122 00010ede RWIX >>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX >>> ERAM 80000000 02000000 00030db8 01fcf248 RWIX >>> and rather than my IRAM used going down, it goes up, and while my Eram >>> goes >>> down I have a net loss. .far is going to ERAM, and all other compiler >>> sections >>> are going to IRAM. >>> can someone explain why this is happening? >> If you make your counters 16-bit variables then I believe the code will >> sign- or zero- extend the variable which can take additional instruction >> cycles (and code space). >> >> What data model are you using for the C compiler: near, far, or >> far_aggregate? (The default is far_aggregate.) >> >> There is probably an alignment constraint on _c_int00 causing it to jump >> to the next 32-byte boundary (i.e. the next fetch packet boundary). > > memory model is far, that was switched a while ago in the project > but I can't remember why. Even if I must have 32 byte (do you mean > bit??) > boundaries, > that still makes no sense as to why my memory usage would INCREASE. > I've only changed things to reduce memory usage, if I'm in a partial > buffer, > then fine no gain, but there still shouldn't be a net increase in > memory usage. > > and if you are correct, what would be the best solution to regain > alignment? > > > At worst it should remain the same. >If your memory model is "far" then all static and global variables will go into the .far section (not .bss). When you change your variables from uint32 to uint16 your ERAM decreases by 4 bytes as expected. Your internal memory increases. I'm guessing it probably increases by 1 or 2 instructions (i.e. 4 or 8 bytes). If _c_int00 is configured in the library for 32-byte (256-bit) alignment, which is the alignment of a fetch packet, then you would see it jump 32 bytes as it does in the snippets above. It would be interesting to look at the listing of all addresses in the map file to see what comes right before _c_int00 and to see how that changes in the 2 scenarios. Brad
Reply by ●May 9, 20072007-05-09
jleslie48 wrote:> > and now that I hooked up my new program to the DSP, I see the > counters as 16bit integers (never going above 1000) isn't working. > most strange. >Make sure you have the latest codegen tools in case it's related to a bug. I assume you have optimization on.
Reply by ●May 9, 20072007-05-09
On May 9, 7:52 am, Brad Griffis <bradgrif...@hotmail.com> wrote:> jleslie48 wrote: > > On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote: > >> jleslie48 wrote: > >>> I'm trying to save usage of my Iram memory so I tried to convert > >>> a few unsigned int to unsigned short, and see the change. I was a > >>> bit surprised by the result: > >>> void TASK_Board1ProcessADC(void) > >>> { > >>> static UINT iCounter = 0; > >>> static UINT iCounter2 = 0; > >>> while(1) > >>> { > >>> results in this map: > >>> ****************************************************************************** > >>> TMS320C6x COFF Linker PC v6.0.8 > >>> ****************************************************************************** > >>>>> Linked Mon May 07 20:39:52 2007 > >>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > >>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > >>> MEMORY CONFIGURATION > >>> name origin length used unused > >>> attr fill > >>> ---------------------- -------- --------- -------- -------- ---- > >>> -------- > >>> IRAM 00000000 00030000 0001f102 00010efe RWIX > >>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX > >>> ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > >>> I make one change, from UINT (unsigned int) to USHORT (unsigned short) > >>> as > >>> so: > >>> void TASK_Board1ProcessADC(void) > >>> { > >>> static USHORT iCounter = 0; > >>> static USHORT iCounter2 = 0; > >>> ****************************************************************************** > >>> TMS320C6x COFF Linker PC v6.0.8 > >>> ****************************************************************************** > >>>>> Linked Mon May 07 20:42:22 2007 > >>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > >>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > >>> MEMORY CONFIGURATION > >>> name origin length used unused > >>> attr fill > >>> ---------------------- -------- --------- -------- -------- ---- > >>> -------- > >>> IRAM 00000000 00030000 0001f122 00010ede RWIX > >>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX > >>> ERAM 80000000 02000000 00030db8 01fcf248 RWIX > >>> and rather than my IRAM used going down, it goes up, and while my Eram > >>> goes > >>> down I have a net loss. .far is going to ERAM, and all other compiler > >>> sections > >>> are going to IRAM. > >>> can someone explain why this is happening? > >> If you make your counters 16-bit variables then I believe the code will > >> sign- or zero- extend the variable which can take additional instruction > >> cycles (and code space). > > >> What data model are you using for the C compiler: near, far, or > >> far_aggregate? (The default is far_aggregate.) > > >> There is probably an alignment constraint on _c_int00 causing it to jump > >> to the next 32-byte boundary (i.e. the next fetch packet boundary). > > > memory model is far, that was switched a while ago in the project > > but I can't remember why. Even if I must have 32 byte (do you mean > > bit??) > > boundaries, > > that still makes no sense as to why my memory usage would INCREASE. > > I've only changed things to reduce memory usage, if I'm in a partial > > buffer, > > then fine no gain, but there still shouldn't be a net increase in > > memory usage. > > > and if you are correct, what would be the best solution to regain > > alignment? > > > At worst it should remain the same. > > If your memory model is "far" then all static and global variables will > go into the .far section (not .bss). When you change your variables > from uint32 to uint16 your ERAM decreases by 4 bytes as expected. > > Your internal memory increases. I'm guessing it probably increases by 1 > or 2 instructions (i.e. 4 or 8 bytes). If _c_int00 is configured in the > library for 32-byte (256-bit) alignment, which is the alignment of a > fetch packet, then you would see it jump 32 bytes as it does in the > snippets above. > > It would be interesting to look at the listing of all addresses in the > map file to see what comes right before _c_int00 and to see how that > changes in the 2 scenarios. > > Bradoptimization is off right now. gosh that issue seems so long ago, I'll try and remember to save off the .map files when I recreate the issue. My software has been through a dozen revisions since the start of this post. Evidence shows I've got a 256-bit alignment scenario, but why would decreasing ERAM requirements result in an increase in IRAM? It still does not follow that in any fashion I have increased IRAM requirements.
Reply by ●May 9, 20072007-05-09
jleslie48 wrote:> On May 9, 7:52 am, Brad Griffis <bradgrif...@hotmail.com> wrote: >> jleslie48 wrote: >>> On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote: >>>> jleslie48 wrote: >>>>> I'm trying to save usage of my Iram memory so I tried to convert >>>>> a few unsigned int to unsigned short, and see the change. I was a >>>>> bit surprised by the result: >>>>> void TASK_Board1ProcessADC(void) >>>>> { >>>>> static UINT iCounter = 0; >>>>> static UINT iCounter2 = 0; >>>>> while(1) >>>>> { >>>>> results in this map: >>>>> ****************************************************************************** >>>>> TMS320C6x COFF Linker PC v6.0.8 >>>>> ****************************************************************************** >>>>>>> Linked Mon May 07 20:39:52 2007 >>>>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> >>>>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 >>>>> MEMORY CONFIGURATION >>>>> name origin length used unused >>>>> attr fill >>>>> ---------------------- -------- --------- -------- -------- ---- >>>>> -------- >>>>> IRAM 00000000 00030000 0001f102 00010efe RWIX >>>>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX >>>>> ERAM 80000000 02000000 00030dbc 01fcf244 RWIX >>>>> I make one change, from UINT (unsigned int) to USHORT (unsigned short) >>>>> as >>>>> so: >>>>> void TASK_Board1ProcessADC(void) >>>>> { >>>>> static USHORT iCounter = 0; >>>>> static USHORT iCounter2 = 0; >>>>> ****************************************************************************** >>>>> TMS320C6x COFF Linker PC v6.0.8 >>>>> ****************************************************************************** >>>>>>> Linked Mon May 07 20:42:22 2007 >>>>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> >>>>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 >>>>> MEMORY CONFIGURATION >>>>> name origin length used unused >>>>> attr fill >>>>> ---------------------- -------- --------- -------- -------- ---- >>>>> -------- >>>>> IRAM 00000000 00030000 0001f122 00010ede RWIX >>>>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX >>>>> ERAM 80000000 02000000 00030db8 01fcf248 RWIX >>>>> and rather than my IRAM used going down, it goes up, and while my Eram >>>>> goes >>>>> down I have a net loss. .far is going to ERAM, and all other compiler >>>>> sections >>>>> are going to IRAM. >>>>> can someone explain why this is happening? >>>> If you make your counters 16-bit variables then I believe the code will >>>> sign- or zero- extend the variable which can take additional instruction >>>> cycles (and code space). >>>> What data model are you using for the C compiler: near, far, or >>>> far_aggregate? (The default is far_aggregate.) >>>> There is probably an alignment constraint on _c_int00 causing it to jump >>>> to the next 32-byte boundary (i.e. the next fetch packet boundary). >>> memory model is far, that was switched a while ago in the project >>> but I can't remember why. Even if I must have 32 byte (do you mean >>> bit??) >>> boundaries, >>> that still makes no sense as to why my memory usage would INCREASE. >>> I've only changed things to reduce memory usage, if I'm in a partial >>> buffer, >>> then fine no gain, but there still shouldn't be a net increase in >>> memory usage. >>> and if you are correct, what would be the best solution to regain >>> alignment? >>> At worst it should remain the same. >> If your memory model is "far" then all static and global variables will >> go into the .far section (not .bss). When you change your variables >> from uint32 to uint16 your ERAM decreases by 4 bytes as expected. >> >> Your internal memory increases. I'm guessing it probably increases by 1 >> or 2 instructions (i.e. 4 or 8 bytes). If _c_int00 is configured in the >> library for 32-byte (256-bit) alignment, which is the alignment of a >> fetch packet, then you would see it jump 32 bytes as it does in the >> snippets above. >> >> It would be interesting to look at the listing of all addresses in the >> map file to see what comes right before _c_int00 and to see how that >> changes in the 2 scenarios. >> >> Brad > > optimization is off right now. gosh that issue seems so long ago, > I'll try and > remember to save off the .map files when I recreate the issue. My > software has been > through a dozen revisions since the start of this post. Evidence > shows I've got > a 256-bit alignment scenario, but why would decreasing ERAM > requirements result > in an increase in IRAM? It still does not follow that in any fashion > I have increased > IRAM requirements. >I already explained that -- using 16-bit counters requires extra instructions for zero-filling the upper bits. Those extra instructions require code space and may then bump _c_int00 to the next 32-byte boundary.
Reply by ●May 10, 20072007-05-10
On May 9, 9:25 pm, Brad Griffis <bradgrif...@hotmail.com> wrote:> jleslie48 wrote: > > On May 9, 7:52 am, Brad Griffis <bradgrif...@hotmail.com> wrote: > >> jleslie48 wrote: > >>> On May 7, 9:43 pm, Brad Griffis <bradgrif...@hotmail.com> wrote: > >>>> jleslie48 wrote: > >>>>> I'm trying to save usage of my Iram memory so I tried to convert > >>>>> a few unsigned int to unsigned short, and see the change. I was a > >>>>> bit surprised by the result: > >>>>> void TASK_Board1ProcessADC(void) > >>>>> { > >>>>> static UINT iCounter = 0; > >>>>> static UINT iCounter2 = 0; > >>>>> while(1) > >>>>> { > >>>>> results in this map: > >>>>> ****************************************************************************** > >>>>> TMS320C6x COFF Linker PC v6.0.8 > >>>>> ****************************************************************************** > >>>>>>> Linked Mon May 07 20:39:52 2007 > >>>>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > >>>>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > >>>>> MEMORY CONFIGURATION > >>>>> name origin length used unused > >>>>> attr fill > >>>>> ---------------------- -------- --------- -------- -------- ---- > >>>>> -------- > >>>>> IRAM 00000000 00030000 0001f102 00010efe RWIX > >>>>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX > >>>>> ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > >>>>> I make one change, from UINT (unsigned int) to USHORT (unsigned short) > >>>>> as > >>>>> so: > >>>>> void TASK_Board1ProcessADC(void) > >>>>> { > >>>>> static USHORT iCounter = 0; > >>>>> static USHORT iCounter2 = 0; > >>>>> ****************************************************************************** > >>>>> TMS320C6x COFF Linker PC v6.0.8 > >>>>> ****************************************************************************** > >>>>>>> Linked Mon May 07 20:42:22 2007 > >>>>> OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > >>>>> ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > >>>>> MEMORY CONFIGURATION > >>>>> name origin length used unused > >>>>> attr fill > >>>>> ---------------------- -------- --------- -------- -------- ---- > >>>>> -------- > >>>>> IRAM 00000000 00030000 0001f122 00010ede RWIX > >>>>> CACHE_L2 00030000 00010000 00000000 00010000 RWIX > >>>>> ERAM 80000000 02000000 00030db8 01fcf248 RWIX > >>>>> and rather than my IRAM used going down, it goes up, and while my Eram > >>>>> goes > >>>>> down I have a net loss. .far is going to ERAM, and all other compiler > >>>>> sections > >>>>> are going to IRAM. > >>>>> can someone explain why this is happening? > >>>> If you make your counters 16-bit variables then I believe the code will > >>>> sign- or zero- extend the variable which can take additional instruction > >>>> cycles (and code space). > >>>> What data model are you using for the C compiler: near, far, or > >>>> far_aggregate? (The default is far_aggregate.) > >>>> There is probably an alignment constraint on _c_int00 causing it to jump > >>>> to the next 32-byte boundary (i.e. the next fetch packet boundary). > >>> memory model is far, that was switched a while ago in the project > >>> but I can't remember why. Even if I must have 32 byte (do you mean > >>> bit??) > >>> boundaries, > >>> that still makes no sense as to why my memory usage would INCREASE. > >>> I've only changed things to reduce memory usage, if I'm in a partial > >>> buffer, > >>> then fine no gain, but there still shouldn't be a net increase in > >>> memory usage. > >>> and if you are correct, what would be the best solution to regain > >>> alignment? > >>> At worst it should remain the same. > >> If your memory model is "far" then all static and global variables will > >> go into the .far section (not .bss). When you change your variables > >> from uint32 to uint16 your ERAM decreases by 4 bytes as expected. > > >> Your internal memory increases. I'm guessing it probably increases by 1 > >> or 2 instructions (i.e. 4 or 8 bytes). If _c_int00 is configured in the > >> library for 32-byte (256-bit) alignment, which is the alignment of a > >> fetch packet, then you would see it jump 32 bytes as it does in the > >> snippets above. > > >> It would be interesting to look at the listing of all addresses in the > >> map file to see what comes right before _c_int00 and to see how that > >> changes in the 2 scenarios. > > >> Brad > > > optimization is off right now. gosh that issue seems so long ago, > > I'll try and > > remember to save off the .map files when I recreate the issue. My > > software has been > > through a dozen revisions since the start of this post. Evidence > > shows I've got > > a 256-bit alignment scenario, but why would decreasing ERAM > > requirements result > > in an increase in IRAM? It still does not follow that in any fashion > > I have increased > > IRAM requirements. > > I already explained that -- using 16-bit counters requires extra > instructions for zero-filling the upper bits. Those extra instructions > require code space and may then bump _c_int00 to the next 32-byte boundary.ah ok, that explanation make sense now. I didn't get your meaning the first time. Thanks.
Reply by ●May 13, 20072007-05-13
In both of your examples you are using static variables in the program scope, but you don't show us the linker command file that says where the .static symbol gets mapped to. On May 7, 5:55 pm, jleslie48 <j...@jonathanleslie.com> wrote:> I'm trying to save usage of my Iram memory so I tried to convert > a few unsigned int to unsigned short, and see the change. I was a > bit surprised by the result: > > void TASK_Board1ProcessADC(void) > { > static UINT iCounter =3D 0; > static UINT iCounter2 =3D 0; > > while(1) > { > > results in this map: > > *************************************************************************=**=AD***> TMS320C6x COFF Linker PC v6.0.8 > *************************************************************************=**=AD***> > >> Linked Mon May 07 20:39:52 2007 > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > ENTRY POINT SYMBOL: "_c_int00" address: 0001c040 > > MEMORY CONFIGURATION > > name origin length used unused > attr fill > ---------------------- -------- --------- -------- -------- ---- > -------- > IRAM 00000000 00030000 0001f102 00010efe RWIX > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > ERAM 80000000 02000000 00030dbc 01fcf244 RWIX > > I make one change, from UINT (unsigned int) to USHORT (unsigned short) > as > so: > void TASK_Board1ProcessADC(void) > { > static USHORT iCounter =3D 0; > static USHORT iCounter2 =3D 0; > > *************************************************************************=**=AD***> TMS320C6x COFF Linker PC v6.0.8 > *************************************************************************=**=AD***> > >> Linked Mon May 07 20:42:22 2007 > > OUTPUT FILE NAME: <./C6713Compact/ORS11x_Demo_C6713Compact.out> > ENTRY POINT SYMBOL: "_c_int00" address: 0001c060 > > MEMORY CONFIGURATION > > name origin length used unused > attr fill > ---------------------- -------- --------- -------- -------- ---- > -------- > IRAM 00000000 00030000 0001f122 00010ede RWIX > CACHE_L2 00030000 00010000 00000000 00010000 RWIX > ERAM 80000000 02000000 00030db8 01fcf248 RWIX > > and rather than my IRAM used going down, it goes up, and while my Eram > goes > down I have a net loss. .far is going to ERAM, and all other compiler > sections > are going to IRAM. > > can someone explain why this is happening?
