Empty while(1) loop

[colinh]

Hi

Just wondering if any compiler gurus have any comments on the use of

while(1){ }; 

or variations thereof for hanging until the COP/watchdog kicks in.  At a code review I attended an opinion was put forward that an optimiser could remove this completely.  Any thoughts?

Thanks
Colin

[bigmac]

Hello Colin,

You do not indicate the MCU family and compiler to which you refer - perhaps the operation may be dependent on this.  However, the following observations would be applicable to the HC908 and HCS08 families.

I could understand that if a loop always exited, such as  while(0); it might be optimised away.  However, this would seem unlikely for a loop that never exited, since program flow would be drastically affected.  Using the default CW compiler options, it would seem that the assembly instuction bra *  is generated for the while(1); loop.

However, a C4000 compiler warning is generated, "Condition always true".  Interestingly, an empty for loop, i.e. for( ; ; ) ;  does a similar thing, but generates no warning, so is my usual preference.

Of course, a simple safeguard against any optimization might be to place __asm nop;  within the loop.

Regards,

Mac

Message Edited by bigmac on 2008-09-20 11:31 PM

[CompilerGuru]

I would be surprised if any C compiler would drop an endless loop for any other reason than a compiler implementation bug. Can happen, endless loops are a bit tricky automatically test.
I don't think any compiler has a switch to make him remove endless loops, at least I never heard of such a thing, and I would not see why a compiler writer should add it.

C optimizers do normally only perform operations which do not alter the visible behavior, the side effects 
(accesses to volatile objects, any change of state visible outside of the optimized code, ...).
I can imagine that some compiler optimize wait loop like "int i; for (i =0; i < 100; i++){}"
but even such loops are often maintained just to keep some code working (even when the compiler detects that they have no other effect than slowing things down).

So any special reasoning why compilers would (be allowed to) remove such loops?
Was anything specific mentioned in that review?

Daniel

[colinh]

Thanks for comments.

The project in question is S12X based, but this is not too relevant to my original post. 

I know there are ways (eg the nop) to ensure  that the loop couldn't be optimised away, but I am trying to work out whether my colleague in the code review is dealing with "real or imagined" potential issues.  Personally I would be absolutely stunned if an optimiser decided to get rid of the loop as it stands, and I am just looking for other informed opinions - particularly whether or not the C standard would allow this to be optimised out.

I am going to go back to the guy in question and find out whether the paranoia is personal or corporate policy, and whether it is backed up with instances etc. 

Cheers
Colin

[Lundin]

The C standard would certainly not allow it. The optimizer isn't allowed to change the meaning of the code. The compiler cannot remove that loop during any circumstances.

Perhaps the optimization referred to the fact that the code doesn't have to check the value of 1 each time, but could rather just jump to the same address over and over ("BRA" rather than "BEQ" on S12). Perhaps one clock cycle could be gained there.

If so, it only matters in multi-process applications were you for example have interrupts running at the same time. Perhaps the interrupts would be delayed with one clock cycle from executing. Since the stacking of accumulations etc when the interrupt is called takes 10 cycles or something like that, it is a ridiculous optimization in 99% of all applications.