Writing Optmized code......

What do you mean by "optimum"?

* easiest to write?

* easiest to debug?

* easiest to maintain?

* fastest execution?

* smallest code size?

* smallest data size?

or what?

Note that some of the above are (or tend to be) mutually exclusive...

Optimum in the sense of fast execution......

Which is an excellent illustration of why just saying "optimum" without qualification is meaningless!

Many of the techniques to give the fastest possible execution will also give larger code size; eg, inlining and loop unrolling.

requires a rarely applied skill: THINKING

Erik

I think that thinking is not enough: it requires especially READING, and having a great interest in learning. I found the document Dan Henry link above really interesting, and in the last months I have been gathering information about how to write good software for embedded systems.

I really don't have a great experience coding (less than two years) and the code I wrote one year ago is completely awful.

The problem is that I work for hardware engineers, to whom coding is not important, and they also code for their designs! The use of qualifiers, function linkage and so doesn't mean anything for them. It's not easy to convince them to read the compiler reference manual.

Well, I was only to expose one situation that I think is common in small companies. I also have some questions about the Keil optimizer (for armcc):

Does the Keil optimizer remove empty delay loops? As far I have seen, it doesn't. (It is typical to warn against this kind of loops, but if Keil compiler doesn't remove them, why not to state it clearly?).

Also, Keil compiler states that down counters generate smaller code (and it is true). Do you use down counters in your loops?: I thought this kind of optimizations were better to be left to the compiler (and the pdf above also says it).

Finally, how and where can I learn more about embedded coding, for the sake of efficiency and fault preventing?

(I also learn a lot in this forum)

Keil compiler states that down counters generate smaller code

yes, but you should note that they are certainly talking about loops that count down to zero.

if you want to learn to program efficiently, you better read an architecture manual of some kind. and most important, experiment yourself. write stuff and then ask yourself: is this code maintainable? easy to extend? is it efficient? how does it give under inspection of a static code analyzer? am I using compiler specific features?
there is nothing wrong developing your own style.

Counting down to zero is a very special case, since a lot of processors have native instructions to decrement and jump if non-zero. A very good instruction to have at the end of a loop to return up again for more iterations.

Good compilers tends to auto-detect when a loop can be rewritten - but that requiers that the code doesn't do too fancy stuff with the loop index.

It must be me, but I don't think I have ever seen a compiler warn about removing an empty loop - either because the loop hasn't been removed, or the compiler does not have such a warning or I have not pushed my luch by having an empty loop :)

I now the old Turbo C/.../Borland C++ did throw away empty loops but I think it did it without warning. Good practice is to write code where you are not relying on the compiler warnings to know that you are pushing your luck. Whenever the compiler has a select to do one of several options, write the code so it doesn't matter which option gets selected.

In the case with an empty loop, you do not really know if it will be fully remoed, or if it will be semi-optimized so it runs fast but does take time, or if it will go the slow way and write down the loop counter to memory and perform a memory reload. This makes it impossible to know how fast the loop will be and makes it extremely dangerous to use empty loops as delays. Having a volatile loop variable will inform the compiler that you want it to perform memory transfers for the loop variable.

I'm not sure if a compiler is allowed to deduce that a volatile variable on the stack and without the address taken will not produce any side effects (except load on CPU and memory subsystem) and if the compiler are then allowed to ignore the loop anyway.