Bitwise Operation is not Producing Expected Result

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

Hi,

I am having an issue with bit wise operators not producing the expected result.  See the attached image.  After I shift enc_val over << 2, the value it contains still has a '1' in the second most lsb spot.  I began with 00000010, after << 2 it was 00001010.  I know I am probably just missing something basic, and am an amateur programmer, so any help is appreciated.
Regards,

Tom 

Attachment(s): 

This topic has a solution.
Last Edited: Wed. Aug 8, 2018 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This could be an effect of the optimizing compiler (avr gcc???)  and its interaction with the debugger.   The optimizer has looked at all of the code in the function and combined operations and is showing the final result without the intermediate steps. Try setting your optimization level to -Og when using the debugger or simulator so it's not so aggressive. 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

Are you sure the <<2 has actually happened at the time of the breakpoint? The compiler is free to reorder the operations. Switch to the asm view and study the opcodes.

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

You definitely should look at the asm, as mentioned.  I wonder if the compiler is recognizing that you are setting your enc_a and enc_b variables to fixed values, and is lumping those last three lines into a single OR of the value 0x02.  I bet if you changed enc_a and enc_b to 'volatile' you'd see different behavior.

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

For sure, if you want the code to operate in the same order as the code was written then a generous helping of "volatile" will help. But the point is the code does not HAVE to work exactly that same order. The compiler is only forced to emit code for a given section of opcodes if it hits a "memory barrier". Without that it can reorder the sequence in whatever way it chooses that might help it to reduce register pressure or make a faster, more efficient solution. "volatile" will just constrain it so it cannot operate as efficiently. Fine for debugging I guess, not wise for when you want an efficient solution.

Last Edited: Thu. Aug 2, 2018 - 03:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
a generous helping of "volatile" will help.

See: https://www.avrfreaks.net/forum/tutcoptimization-and-importance-volatile-gcc

 

the point is the code does not HAVE to work exactly that same order.

See: https://www.avrfreaks.net/forum/shortcuts-taken-optimized-code-may-occasionally-sic-be-surprising

 

 

And note that this all applies generally to any compiler for any target - it is not specific to AVR or Atmel Studio or GCC ...

 

https://www.avrfreaks.net/commen...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

"volatile" will just constrain it so it cannot operate as efficiently. Fine for debugging I guess, not wise for when you want an efficient solution.

Right.  The OPs code is in a sense 'artificial', with real variable assignments replaced by assignments of constants.  The compiler is no doubt picking up on these and replacing runtime code with compile-time constants as a result.  'volatile' would prevent this and the OP would see what he expects to see, but it is really just a teaching moment, not something you'd put in actual code.  (however, any variables communicating between ISR and background code DO need to be declared 'volatile', to prevent the compiler from optimizing away desired data flows, which may be the most important lesson the OP takes away from all this)

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

Thank you, this was instructive to me.  I will have to learn some more about using/reading the assembly code.

Regards,
Tom

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

If you read the first link in #6 then you will learn that most of the time you can get results more like you expect if you apply "volatile" and it needn't involve studying the Asm. However only do it while devloping/debugging because volatile (or the ultimate sanction which is building -O0) lead to very inefficient code as you are turning off the compiler's ability to think smart.

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

clawson wrote:
If you read the first link in #6 then you will learn that most of the time you can get results more like you expect if you apply "volatile" 

Or read the 2nd link - then you will learn to have better expectations ...

 

wink

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah but you see that very first link is a work of total genius. (don't ask me how I know this!)