How many clock cycles does an "If" take on a Nano? What about an "If/Else"?
From the AVR 8-bit Instruction Set doc, there's a "Compare" (CP) and a "Branch if Equal" (BREQ) with syntax of "if (Z = 1) then PC ← PC + k + 1". What does this mean?
Are these the right statements for an "If"?
That depends on the compiler. There are many optimizations, and the compiler can change code, or rearrange code.
There is an option to let the compiler generate an assembly listing, but I forgot how to do that.
According to this, the elf file contains also debug info : How can one view the assembly code output from the Arduino IDE? - #9 by westfw - Programming Questions - Arduino Forum
Here is a detailed tutorial for that : Arduino Assembly Language Listing of Compiled Sketch (Windows) | µC eXperiment
The cycles will mainly be used in evaluating the condition, not the jumping.
rickso234:
How many clock cycles does an "If" take on a Nano? What about an "If/Else"?
if ( true )
{
Serial.print( F( "true" ) );
}
else
{
Serial.print( F( "false" ) );
}
The correct answer is "zero". The optimizer eliminates the condition and the else-clause.
This
"if (Z = 1) then PC ? PC + k + 1"
is pseudo-microcode which explains how the BREQ assembler instruction works.
If the Z status bit (which indicates a Zero or equal condition) is set then the PC (Program Counter) is set to the address of the instruction which the BREQ points to. Otherwise it does nothing which implicitly means it will execute the instruction immediately after the BREQ.
This has nothing to do with the if statement in the C/C++ language.
Why do you need to know how many clock cycles are taken by an if statement? The question is almost meaningless and/or futile because you have or no control over how the compiler converts a C "if" statement into assembler.
Pete
Or to put it more subtly: You do not perform time-critical coding in "C", so if that is what you think you are doing, think again! 
Paul__B:
Or to put it more subtly: You do not perform time-critical coding in "C", so if that is what you think you are doing, think again!
I disagree.
I have done many time critical things in C over the past 30+ years of embedded programming including many high-volume commercial products.
You just have to have a proper design and take into consideration the limitations.
Usually the limitations are quite minimal. In some cases, it does require paying close attention to the compiled code generated.
And you must follow up with verifying that you are keeping within your real-time constraints.
If you look around you can even find some arduino code that outputs video on a pin by doing real time bit banging
and that code is written in C.
There is a nice speech library that also does realtime bit banging, also written in C.
The IR and servo libraries, also written in C, have lots of realtime constraints.
My saying that I used to try to get the younger guys to think about was:
"Better algorithms, beats faster code every time".
Meaning: always optimize the system as whole rather than jump in and try to micro optimize individual routines.
But these days I see many young whipper snapper programmers think that they can write code without ever doing a design and expect it to magically work, and when it doesn't, blame the speed of the processor.
--- bill
The timing of of an IF statement will vary significantly depending on the contents of the test. The comparison of a byte variable with a constant will probably generate the minimal CPI, BRNZ instructions that you'd expect. ints are slower, longs slower than that, and I suppose that you can create a complex floating point expression that would be very slow indeed. Any functions you call (digitalRead(), Serial.available(), etc) is also slower than a simple expression.
You do not perform time-critical coding in "C"
Meh. It's not like you're going to do better by coding the same operation in pure assembler. Sure, you can more easily calculate exactly how long it will take (assuming you don't call any opaque functions.) And maybe it won't change "randomly" when you change compiler versions, or due to apparently unrelated code "nearby." But you're much better off keeping the "amount of time criticalness" much smaller than either C or asm would provide, rather than counting on clever coding to save you 5 cycles...
Okay, thought I'd get away easy on his one. Looking to detect a repetitive pulse that's in the order of 50ms wide and repeats about every 500msec. The main loop that looks for this pulse contains a half dozen "if's", and a digital and an analog read, and needs to execute quickly enough to be able to capture the next pulse. When a pulse is detected, it blinks a few LEDs then returns to the main loop.
I can use an ISR to look for the pulse's rising edge but keeping it simple for now (or until necessary). At 62.5nsec per clock cycle and instructions taking a few clock cycles each, should be plenty of time to detect the beginning of the pulse. Detection of the exact rising edge isn't critical, but would like to detect the pulse no more than a few msec into its occurrence.