SV: SV: SV: [Icc-avr] Stack problems

[Bengt Ragnemalm]

One more question about this.

If I declare a local array that is larger than the RAM, I do not get an
error. Is that because the compiler can not be sure that this array will
actually be placed in RAM as it can point to anything?

/Bengt

> -----Ursprungligt meddelande-----
> Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr-
> bounces at imagecraft.com] För Richard Man
> Skickat: den 18 augusti 2008 10:25
> Till: icc-avr at imagecraft.com
> Ämne: Re: SV: SV: [Icc-avr] Stack problems
> 
> The compiler does lifetime analysis for simple variables, but almost
> no compiler does analysis for aggregates. Why not? Consider this?
> 
> void Function(void)
> {
>    unsigned char array1[512];
>    unsigned char array2[512];
> ...
> 
> array1[512] = ...;
> 
> this *may* write to the first element of array2, of what if the
> programmer writes
> 
>          if (cond)
>                  p = array1;
>          else
>                  p = array2;
> 
> point is the problem is A LOT more difficult than one may think. I'd
> welcome anyone who thinks writing a compiler is easy to produce a
> production quality compiler that people can rely on. You have to know
> the limitations of the microcontroller and the power+limitations of
> the language you use. There is no magic bullet. I am not so sure why
> you consider it is "easy" to write a heroic compiler, rather than
> understanding the limitations of the hardware and the language
> impose. You cannot pick and choose the subset of C that gives you the
> best code for *your* writing style, you must live with all the power
> that C gives you but you must also know its limitations.
> 
> At 12:48 AM 8/18/2008, Bengt Ragnemalm wrote:
> >Yes, you are absolutely right. So the programmer must have good knowledge
> of
> >about how long, how thick and the material strength of the rope? Damn,
> and I
> >who thought I used a ladder. (C=rope, Pascal=ladder, Basic=elevator,
> brick
> >wall=assembler???)
> >
> >A question: Does this mean that the compiler never have any control over
> if
> >the RAM used for local variables by a single function are more than total
> >RAM-global variables? This is what happened. I couldn't see how this can
> be
> >such a big deal for the compiler.
> >
> >The code actually runs fine even after the "crash", it depends on what
> >registers are overwritten (of course). It would have been easier to find
> if
> >it did not. The reason for that the Stack Checking function didn't find
> >anything was that the code at the time of using the 512 byte string in
> one
> >step moved the RAM usage outside the RAM. And as the program didn't
> filled
> >the entire string the Stack Checking bytes was never overwritten. It
> would
> >of course resulted in bigger problems in the future as more of the string
> >will be used.
> >
> >Maybe it could be that the compiler have problem of freeing the RAM space
> >for the first array before the RAM space for the second array are used. A
> >local array should be to prefer as it would use less RAM in the total
> >application but a global may be necessary if that is the only way to see
> >that the function defines to much RAM.
> >
> >The code is something like this:
> >
> >void Function(void)
> >{
> >   unsigned char array1[512];
> >   unsigned char array2[512];
> >   unsigned char sendData;
> >   ...
> >
> >   for(...)
> >   {
> >     array1[...]=...;   // Reading values to array 1
> >     array1[...]=...;
> >     ...
> >   }
> >   if (globalFlag)
> >   {
> >     for(...)
> >     {
> >       sendData = array1[...];
> >     }
> >   else
> >   {
> >     SendArray(array1);  // Last usage of array 1
> >     array2[...]=;  // Some usage of array 2
> >     array2[...]=;
> >     ...
> >     SendArray(array2);  // Last usage of array 2
> >   }
> >}
> >
> >/Bengt
> >
> 
> // richard (This email is for mailing lists. To reach me directly,
> please use richard at imagecraft.com)
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr