AVR studio with built in optimization features??

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have this code compiled with IAR (latest release as received from IAR) and no optimization.

      
1: if (CaptureValue > 0)  /* CaptureValue is updated by capture interrupt */
2: {
3:   if ((CaptureValue >= Table[TableIndex].MinValue) &&
4:      (CaptureValue <= Table[TableIndex].MaxValue)) 
5:    TableIndex++;
6:  else
7:     TableIndex = 0;
8:
9:CaptureValue = 0;
.
.
.

As seen by the first comment the variable CaptureValue is updated by the capture interrupt (timer 1, Atmega16) by setting CaptureValue = ICR1.
CaptureValue is declerated as

static WORD CaptureValue;

Now, while I debug, and if I set a breakpoint in line 3, I can read the value of CaptureValue, but if I set the breakpoint in line 5 the watch window says that CaptureValue is "optimized away". I cant figure out why. Can you?

Note: If I set the breakepoint in line 3, and if using the step command, the same shit happens when I get to line 5 until I step line 9. Then the CaptureValue is set to 0 as expected. The program works as expected but it does not feel good to not understand (i am very often sick),,, Is this a bug in studio or what?

Thanks in advance

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just an idea but maybe try declaring CaptureValue "volatile" ?

It's often the case that when you share a variable between an ISR that is updating it and a main application code that's then using it that in the main code the compiler cannot "see" any reason why the variable will be changing so optimises it into a local register that is just read from the 'CaptureValue' storage location at the top of the routine. If the ISR later updates what is stored in that storage location the main app code isn't aware of the change because it's just held locally in R24 or whatever. Adding 'volatile' to the declaration tells the compiler - "even though you can't see it, this variable is likely to change behind your back so every time an access is made generate code to re-load it from the RAM storage location and don't just optimise a local copy into a CPU register" (or words to that effect)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I understand, but this is not the case here since the test in line 3 can see the value and when setting CaptureValue = 0 in line 9 it is in fact cleared, and the capture interrupt can update the variable with the ICR register value. Also, remember that this is the IAR compiler and it does not optimize away unused variables like winavr (gnu) does when not told to do so! (.. a kick in the as to the gnu compiler). :wink:

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not a matter of being able to just "see" a variable. It's a matter of the compiler's knowledge who might modify this variable vs. the actually possibly modifiers of this variable. In declaring a variable as volatile, you explicitly tell the compiler that it must not use any assumptions regarding potential accessors to this variable and will not do any optimization on that variable.

This has nothing to do with a variable just being optimized away.

-- Thilo

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, but since I clearly can, lets say "read" the variable, in the line abov, and "write" to the variable a few lines below line 5 and also in the capture interrupt, then volatile or not volatile is not the problem here. Note that the variable is allocated in SRAM and not a register, (i know i know i know, that registers is also stored in SRAM, but let us then use the terminology "stored in memory" in stead). However, I personaly believe there is a bug in avrstudio (i am not saying that it is so, though), but I youst wonderd if anyone have had similar problems/symptoms.

Thanks anyway for the information given

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Last Edited: Thu. Sep 15, 2005 - 11:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK but just for the hell of it please try declaring it volatile then report back whether this fixed the problem or not?

I've got £5 says it DOES fix it!

(the volatile/shared var/ISR/main app thing is problem number one here which is why it's FAQ entry number one ;) )

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bet 1000 greens against you.

Lets go.
...

...

Times pass away

...

---

<*gasph! °'
---

---

There is someone comming. He sits down in front of his
keyboard, tapping gently on the letters.
and here's what he wrote.

...Nope, sorry, IT DOES NOT FIX IT. Haa haaa haaaaa..argh
Please transfer your mony to my account...
:lol:

Yes, i know aboute the FAQs, but as said, volatile is not the problem.
But ok, i guess i have to live with it :)

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, try this, with the code loaded into AVR Studio right click a source line and then select "Goto disassembly" then locate this code and select the relevant section (source + asm) with the mouse, Ctrl-C it then Ctrl-V it into a message here (wrapped in {code}/{/code}) so we can see what asm was generated for each source line.

Cliff