Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

In article 96-03-091,
Scott A. Berg <sberg@camtronics.com> wrote:
] 1 - Lousy C code can fool a compiler into thinking no optimization is
] possible. There is only so much "smarts" possible with compilers.
] For example, common sub-expression extraction can be fooled by using
] parentheses "for clarity" but which fool the parse tree into thinking
] two equivalent expressions are different.


It is possible to reorganize the parse tree into a "canonical
representation". Of course, if the parenthesizing makes the two trees
different enough the compiler might not notice the equivalence. But if
you're able to notice the equivalence and factor it out manually (in C
or assembly) it's probably not harder and not less readable to put the
parentheses in such a way that it's obvious to the compiler that the
two expressions are the same.


On another hand, the problem of alias-analysis which might fool the
compiler into thinking that 2 expressions are not equivalent because
some assignment inbetween might change the result is more
difficult. In such cases manual CSE might be useful.


] 2 - C includes some under-used features to help the compiler.
] "register", "static" and "const" are three keywords that can have a
] major impact on resulting code, but they are used too little due to
] their not being well understood.


Anybody looking for speed should know about const, static and
register. But note that a pass through the profiler with feedback to
the compiler generally gives better results than manual annoations of
"register". Similarly, global analysis can make "static" annotations
needless. And "const" can also be inferred from a global analysis. So
a good compiler doesn't need those annotations.


On another "const" and "static" a very good documentation-annotation.
And "register" annotations can be useful in the absence of feedback
from a profiler and/or if you use a non-optimizing compiler.


] 3 - The ability to assign a value as part of an if statement, e.g., if
] (x=(y+2 > z)), was designed to make it easy for the compiler to spot
] when an expression value can be assigned to a register and used for
] several operations. This construct is seldom used because it can be
] confusing. LINT usually throws a fit over this one. Thus, a feature
] that is useful for speed is seldom used due to clarity.


I doubt any recent C compiler takes advantage of it. More precisely,
temporary variables don't cost anything since they are introduced by
the compiler anyway. For instance


                if (x = (y = (a++ * d[f]) + (b * d[f] - e))) {


is strictly equivalent (for the compiler) to


                tmp0 = d[f];
                tmp1 = a * tmp0;
                tmp2 = b * tmp0;
                tmp3 = tmp2 - e;
                y = tmp1 + tmp3;
                a = a + 1;
                x = y;
                if (y) {


in other words, even the programmer that wants his code to go fast
should concentrate on the readability of his code more than on using
tricks like '+='. Of course, this doesn't rule out '+=' since it's
sometimes more readable than the obvious alternative.


                Stefan
--

Return to the comp.compilers page.
Search the comp.compilers archives again.