Hi lionlhill
youp, you are right, but we must not forget that not all compilers have equally well designed optimization techniques buildin. With those compilers you are happy to give him some hints. This is espassially true for C, because C is not a pretty languge, but it gives you control over generated code near assembly with advantage from structured programming. An example for additional hints that you can give the compiler is pre- and postincrement. You can write
a = a + 1;
or
a++;
which are equivalent. But suppose the compiler does not notice this equivalence, he could generate for the first
move r1,@a
move r2,1
add r1,r2
move @a,r1
and for the second
inc @a
(I truly know of an architecture capable of incrementing memory values directly).
IMHO a programmer, which does not worry about what a compiler does, should not program at all. This might be a very harsh point of view, but if you have to deal with microcontrollers and DPS's, then you have to now about the last bit that is changes (no joke!). This view might, of course, not hold for WinDOSE or GUI applications, but evben there it would be wise to have a good understanding of what a compiler generates.
Now to optimizing using inline assembly: ther are some types of code, which are done best in assembly. E.g. if you write an OS and you develop context switch, then you will have to write parts of it in assembly. Thera are other examples, e.g. special features of your architecture, that you can not access otherwise. But beware, keep assemlby code to an absolute neccessary minimum. This is why we have higher level languages, because maintaining assembly is a pain.