SV: SV: [Icc-avr] Stack problems

Richard Man richard-lists at imagecraft.com
Mon Aug 18 01:24:34 PDT 2008


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) 



More information about the Icc-avr mailing list