Lpc2000

I may be doing things wrong, but my tests show something different.  I'm 
also using GCC 3.4.3.

I assume that something mapped as .data will be copied to ram, .rodata will 
not be?

Here are my results:

char * test1p     = "test 1 pointer"; // .data
char   test1b[]   = "test 1 bracket"; // .data
char   test2b[]   = {'t','e','s','t',' ','2',' 
','b','r','a','c','k','e','t',0}; // .data
const char * test3p     = "test 3 pointer"; // .data
const char   test3b[]   = "test 3 bracket"; // .rodata
char const * test4p   = "test 4 pointer"; // .data
char const   test4b[] = "test 4 bracket"; // .rodata
char * const test5p   = "test 5 pointer"; // .rodata
char   const test5b[] = "test 5 bracket"; // .rodata
const char const * test6p   = "test 6 pointer"; // .data
const char const   test6b[] = "test 6 bracket"; // .rodata
const char   const test7b[] = "test 7 bracket"; // .rodata
const char * const test7p   = "test 7 pointer"; // .rodata
char const   const test8b[] = "test 8 bracket"; // .rodata
char const * const test8p   = "test 8 pointer"; // .rodata
const char const   const test9b[] = "test 9 bracket"; // .rodata
const char const * const test9p   = "test 9 pointer"; // .rodata

Note that I made a dummy function call that read from all of these arrays.

I'm confused with test3,4 and test1.  Both test1s are mapped to data; 
however test3,4p are mapped to data, but test3,4b are mapped to rodata.

Most of that makes sense, and most of the following does:

test1p[0] = 'f'; // .data; ok
test1b[0] = 'o'; // .data; ok
test2b[0] = 'o'; // .data; ok
test3p[0] = 'b'; // .data; nok
test3b[0] = 'a'; // .rodata; nok
test4p[0] = 'r'; // .data; nok
test4b[0] = 'f'; // .data; nok
test5p[0] = 'o'; // .rodata; ok   ****
test5b[0] = 'o'; // .rodata; nok
test6p[0] = 'o'; // .data; nok
test6b[0] = 'o'; // .rodata; nok
test7p[0] = 'b'; // .rodata; nok
test7b[0] = 'b'; // .rodata; nok
test8p[0] = 'a'; // .rodata; nok
test8b[0] = 'a'; // .rodata; nok
test9p[0] = 'r'; // .rodata; nok
test9b[0] = 'r'; // .rodata; nok

Except for test5p -- it's mapped to .rodata yet the compiler allows me to 
try to change it, while it won't let me change test5b??

-- Sean


At 06:38 2/11/2006, you wrote:
>Hi, Sean. From tests I did with GCC 4.0.1, I came into the conclusion
>that:
>
>char* test1 = "TEST1"; <--- doesn't get copied to RAM
>char  test2[] = {'T','E','S','T','2'}; <--- does get copied to RAM.
>
>i.e., omiting the const modifier is not enough to make strings be
>copied to RAM. Strings declared with double quotes are considered
>const whether we say so or not. There are options to explore besides
>this. For instance, you can specify the section where you want your
>variable placed (.text, .data, etc.); I did no tests with that.
>
>Guille
>
>--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@...> wrote:
> >
> >
> > Strings literals are stored in flash and copied into RAM as part of
>the
> > startup of the application (along with all other preinitialized
> > variables).  However to be safe it's better to explicitly declare
>anything
> > you want to be in flash as const.
> >
> > If you didn't declare the array that you were using for is_any as a
>const
> > then the string data would be copied from flash to ram at startup.
>If it
> > is declared as const then it stays in flash and is referenced
>directly from
> > there without a ram counterpart.
> >
> > -- Sean
> >
> > At 20:46 2/10/2006, you wrote:
> > >Sean,
> > >
> > >Thanks.  Does this mean the compiler does not 'move' strings like
>this
> > >into ram?  So, I need not worry about the 'const' label?
> > >I have a huge font array that I want in flash of course.
> > >
> > >TIA
> > >
> > >Glen
> > >
> > >
> > >Sean wrote:
> > > > test.c:32: warning: passing arg 1 of `is_any' discards
>qualifiers from
> > > > pointer target type
> > > >
> > > > this is because you're passing a "const uchar *" as a "uchar *"
> > > > param.  Changing either the function to is_any(const unsigned
>char
> > > > *,char)  or removing const from the string declaration removes
>this
> > > > warning, but it's only a warning, it won't effect the execution.
> > > >
> > > > -- Sean
> >
>
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel 
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic 
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------