In this code a youtube poster said the compiler optimizes out the division time, that the digitalwrite is the slow part of the code. Thoughts? Here's the partial code.

void IRcarrier(unsigned int IRtimemicroseconds)

{

for(int i=0; i < (IRtimemicroseconds / 26); i++)

{

    digitalWrite(IRLEDpin, HIGH); //turn on the IR LED

    //NOTE: digitalWrite takes about 3.5us to execute, so we need to factor that into the timing.

     delayMicroseconds(9); //delay for 13us (9us + digitalWrite), half the carrier frequnecy

    digitalWrite(IRLEDpin, LOW); //turn off the IR LED

    delayMicroseconds(9); //delay for 13us (9us + digitalWrite), half the carrier frequnecy

}

}

The video is here.
The full code is here.

 

The claim might be valid for some hardware platforms and for others the claim would be preposterous. The only way to be sure is to dump the compiler's assembly language output. The key here is that the value can be computed outside of the loop. If that is true and the platform has an integer compare instruction, then the claim is plausible. I'm guessing more time is wasted setting up stack frames and calling and returning from functions, but what do I know?

Next time you include a code fragment please enclose it in

...

brackets to preserve the indenting, making it easier to read.
Thanks ever so much.

 

The code tags didn't pretty it up much so I did it manually. Looked at dumping the compiler's assembly language output. What a pain in the A%%! At least I got an answer. Maybe someone else will be able to wade through this 7 lines of code.

 

Optimizes out WHAT division time? The only one I see is in the for loop "IRtimemicroseconds / 26"

Since IRtimemicroseconds is an unsigned int it is unknown at compile time and is NOT optimized out.

It is performed (hopefully just once) the for loop is called. It may also be called each time the loop loops, that is compiler specific as it needs to retain that value.

I doubt it does as nothing prevents IRtimemicroseconds from changing during the loop so it needs to be computed each time. Only a very expensive optimizing compiler could notice that.

 

Ernie, this is what I kinda figured. It is a variable and thus subject to change. This was written for an arduino. I figured it would have to be a sophisticated compiler indeed. It would have to "run" the program first, decide what this variable will change to and store these numbers in memory to be used when the program is burnt and really runs; very intuitive! Secondly, division on Atmel chips has been known to slow in comparison to other operations. Bottom line is we have no proof no matter how unlikely.

 

The code tags didn't pretty it up much so I did it manually. Looked at dumping the compiler's assembly language output. What a pain in the A%%! At least I got an answer. Maybe someone else will be able to wade through this 7 lines of code.

Where is the assembly language output. I'll wade through it and give you an answer.

BTW - the value of IRtimemicroseconds cannot change inside the function. It never occurs as an lvalue. It is not passed to any of the subsidiary functions that are called. It is passed into the function on the stack frame, the termination value involving the division should be performed before the loop begins, and kept on the stack as a temporary variable. I don't think the optimizer will ever be concerned with this code.

 

Der! PapaB is correct. ("...the termination value involving the division should be performed before the loop begins, and kept on the stack as a temporary variable.") I've been away from programming for so long. I don't even know where to begin at getting the assembly output of this code. I've just been working with the Arduino IDE. The last time I messed with C I had trouble just using makefiles. Thanks all for your thoughtful responses. And Ernie I may have misunderstood your post.

 

Yeah. I don't know if you can access the assembly language code from an Arduino sketch. Supposedly they use the GNU compiler and if the shetch output file is an ELF or other compatible format then the objdump utility may be of use to you. Give it a whirl.