Lpc2000

--- In lpc2000@yahoogroups.com, "Guillermo Prandi" <yahoo.messenger@m
...> wrote:
>
> I too gave a suspicious look at the startup code. But the thing is, 
> in order to copy the modifiable data to RAM it must be in the ROM in 
> the first place! It doesn't show in the lst file, whilst puts() 
> parameters do.

They will be in a different area.

A constant string will be on the rommable constants area (.rodata in 
GNU talk).

A modifiable string will be in the data initialisation section (.data 
in GNU talk). This is rommed, but is copied into RAM for the 
execution.

> 
> I tried giving a const to the function's declaration, with no luck.

No luck expected :-). consting a function just says that the function 
will not try to modify the string that it is passed. It does not 
modify the placement of the string.
 
> However, I narrowed down the problem to auto-inlining: if I move the 
> do_something() function to another source (I was testing with an 
> empty body on the function!), the strings do show in the .data. This 
> kinda makes sense, since the compiler realized that there was no 
> point for that constant to be in the code in the first place. What 
do 
> not makes much sense (but works well somehow) is:
> 
> char   d[20];
> char* c = "AAAAAAAAAAAAAAAAA";
> 
> d[0] = *(c++);
> d[1] = *(c++);
> d[2] = *(c++);
> d[3] = *(c++);
> 
> Here there's some weird optimization choices: instead of storing a 
> number of A's and copying them without hesitation, the compiler 
> *knows* they're all A's, so it loads an A in r2 and repeats it along 
d
> [n]... :P If I change "AAAAAAA..." for "ABCDEF....".... it changes 
an 
> A in r2, a D in r3, stores them in d[0],d[3], then performs ADD r2, 
> r2, #2 and SUB r3, r3, #2 and stores r2 and r3 in d[1], d[2]. 
> WTF!!!!!!!

The compiler writer sure is on a high caffiene diet! Pretty clever!
 However, even if you'd used and arbitrary string, I'd expect it to 
work and here's why. The string is held in const, but gets copied into 
the d[] array by your code. Therefore your code is more-or-less doing 
what startup code should do.

> 
> OK, then it works. Oddly, but works. It's my fault for making so 
> small test cases.
> 
> Guille
> 
> 
> --- In lpc2000@...m, Robert Adsett <subscriptions@a...> 
> wrote:
> >
> > At 11:08 PM 10/17/05 +0000, Guillermo Prandi wrote:
> > >Hi! Has anybody found this? I'm using gcc 4.01 (latest WinARM) 
and 
> I'm
> > >compiling for LPC2138 (ARM7). If I use this kind of stuff, 
> constants
> > >don't get to the HEX file:
> > 
> > It sounds like a problem with your startup code.
> > 
> > 
> > >char *c = "Hello";
> > 
> > 
> > This string, for instance needs to be copied to RAM since your 
> declaration 
> > indicates it's modifiable.
> > 
> > 
> > >or
> > >
> > >my_func("Hello");
> > 
> > 
> > As will this if my_func is prototyped as void my_func (char *)
> > I think that's the case.
> > 
> > 
> > >However, if I use a built-in function like printf or puts, they 
> do!:
> > >
> > >printf("Hello");
> > 
> > 
> > This however can point to the string in flash since printf expects 
> a const 
> > string.
> > 
> > The prototype is something like
> > 
> > int printf( const char *, ...);
> > 
> > 
> > Question:  Does the problem disappear if you declare the first 
case 
> as
> > 
> > const char *c = "Hello";
> > 
> > and prototype the function in the second as
> > 
> > void my_func( const char *);
> > 
> > 
> > 
> > 
> > >This only happens with -On, where n != 0.
> > 
> > 
> > I'd be really confident that was the problem, except I don't see 
> how this 
> > final statement fits in.
> > 
> > Still the const/non-const nature of the two cases cries out as 
> being 
> > critical.  Maybe you are writing over the strings in RAM?
> > 
> > Robert
> > 
> > " 'Freedom' has no meaning of itself.  There are always 
> restrictions,   be 
> > they legal, genetic, or physical.  If you don't believe me, try to 
> chew a 
> > radio signal. "  -- Kelvin Throop, III
> > http://www.aeolusdevelopment.com/
> >
>