SV: SV: [Icc-avr] Stack problems

[Andrew]

Hi,

 

Surely at some stage a static variable will end up being placed in SDRAM, if the function that uses the variable is called, one would hope the complier tells the user the variable is too big.

 

Although i did try this and the compiler did show me an error: --

 

void test (void)
{

 static unsigned char Test[8192];
 
 return;

}

Note; i am using a Atmega 640 (8K) of RAM




So as far as i can see it works fine.


Andy



----- Original Message ----- 
From: "Bengt Ragnemalm" <benra at imt.liu.se>
To: "'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.'" <icc-avr at imagecraft.com>
Sent: Thursday, August 21, 2008 1:55 PM
Subject: SV: SV: SV: [Icc-avr] Stack problems


> 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
> 
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080821/545d433b/attachment.html