I think we are discussing not the solution :-)
The compiler optimizes unused code away, that is OK!
If we use a volatile, the WRITE ACCESS could not longer be optimized and
also a new READ ACCESS before subtraction must! be done. That is what
the compiler do, that is also OK!
If there is a "local" volatile variable, the compiler build a new stack
frame which results in a big prologue and epilogue for the function,
which is OK!
The solution to have a time consumtion function is to use the library!
Sorry that the volatile hack is not what you need. But it burnes time as
expected :-) and nothing else is requested. If you need a handcafted
delay loop use inline assembler instead. The behaviour of the compiler
can change from version to version. And I hope it will change a lot to
get better code!
Bye
Klaus
Royce Pereira wrote:
So I have to write more 'C' code :) to get the same
stuff done, in the 'new & smarter' compiler!
Not more code, just correct code.
Have you tried returning the final value of your delay argument from the
function? If the compiler optimizes only within the boundaries of
individual functions it won't be able to take advantage of the fact that
the result is not used. Strictly, this isn't correct either as the
compiler could just assign zero and return. But, it may not be smart
enough to do that and you may get closer to your original assembly
language. Another way to go would be to write the function directly in
assembly language.
Graham.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list