Efficient bit checking in embedded C Program

Question

I am using AVR controller atmega328. I need to check the status of two bits. I have two approaches, but not sure which one is most efficient. In first case in the code below, I am reading the port using PIND command twice (Two times PIND access is made). So is this an issue or I have to go with second if statement?

#define SW1 2
#define SW2 5
//check if both are high
if((PIND&(1<<SW1))&&(PIND&(1<<SW2))) 
//Or
if((PIND&((1<<SW1)|(1<<SW2)))==((1<<SW1)|(1<<SW2))) 

Answer 1

I suppose PIND is a peripheral register (what do you mean by "command"?).

The first check will read it once or twice, depending on the first comparison. This might generate a glitch, if SW1 changes between the first and second read.

Presuming SW? are switches: In general, it is better to read such a register once (possibly to a variable) and test for the bits. That ensures you get a snapshot of all input bits at the same time.

Also, the seconde version is not necessarily slower, as it safes a branch (IIRC AVR has no conditional instructions other than branch/jump).

Answer 2

Its hard to say which of the above 2 will be more efficient without the output of assembler. However i would guess that the difference in performance would be very little.

In case 2 you are avoiding reading the registers twice but you are performing 2 additional operations.

If i were to make a guess i would say that option 1 would most likely to be faster since PIND is a AVR regsiter and the cost of reading would be less.

Having said that i would suggest using the first option as its more readable even its not found to be faster than option 2.

Answer 3

The first reads PIND twice so is less efficient and a potential for error - the time between reads may be significant if interrupts or thread context switches intervene.

The second evaluates (1<<SW1)|(1<<SW2) twice, but in this case it is a compile time constant, so should have no impact on performance. But to be honest you are probably sweating the small stuff worrying too much about the code at this level. If you really need to know; take a look at the code the compiler generates (in the debugger disassembly or by getting the compiler to output an assembly listing), but it will take a long time to write code if you intend to second guess every line like this,