We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I came accross this code fragment when reviewing some sample code for ethernet. Didnt even try to build it. Would the delay function even be called if no executable code is in the body? I would think it would be optimized out under all circumstances? In my opionion, its not the right way to do it anyway...
Just curious ...
static void delay (void) {;}; /*--------------------------- output_MDIO -----------------------------------*/ static void output_MDIO (U32 val, U32 n) { /* Output a value to the MII PHY management interface. */ for (val <<= (32 - n); n; val <<= 1, n--) { if (val & 0x80000000) { GPIO2->FIOSET = MDIO; } else { GPIO2->FIOCLR = MDIO; } delay (); GPIO2->FIOSET = MDC; delay (); GPIO2->FIOCLR = MDC; } }
Would the delay function even be called if no executable code is in the body? I would think it would be optimized out under all circumstances?
Not under any circumstances. Under most, probably. That's interesting, though: what's a portable way of creating a short delay? Reading a dummy volatile variable, maybe?
"Would the delay function even be called if no executable code is in the body?"
it depends on the compiler.
"In my opionion, its not the right way to do it anyway..."
it depends on what you want to do. you certainly CAN create delay with that. but that doesn't mean that you WILL create delay with that piece of code: you run a variety of risks with it.
whether that (taking the risk) is justified or not depends on your particular application.
That's interesting, though: what's a portable way of creating a short delay? Reading a dummy volatile variable, maybe?
I would personally use 'ASM NOP' or something equivalent to ensure a delay within the processor. A dummy function call is a bad choice for a delay, as it may not get compiled-in in many situations/environments. Additionally, if the delay must be precise, interrupt processing must also have to be accounted for as a possibility. Not to mention task preemption if in an RTOS. Etc..Etc..Etc...
Just thought this was strange. But, no author on/in the code, so no accountability here...
a NOP can be optimized out, and a series of NOP without disabling interrupts suffers from the same problem.
there are many ways to get around the "optimization" issue here, and some of them are incredibly simple and effective.
"if the delay must be precise"
maybe that's the point here: the author may not have wanted / required precise delays here.
"a NOP can be optimized out"
Yes and no. Many compilers have a specific NOP primitive that they know they must not optimize away.
See for example: infocenter.arm.com/.../index.jsp
In most cases, when nop is used, it's enough to guarantee a minimum delay. It's normally thinks like settle/hold times for external signals.