E
Eric Sosman
No, not even that much is sure. Furthermore, you *want*
this uncertain state of affairs! In `z = (x + y) * (x + y);' for
example, you *want* something like `z = x + y; z *= z;', which
means you *want* to discard one of the additions precedence and
associativity appear to demand.
Or, how about common sub-expressions? If the compiler sees
the same (side-effect free) sub-expression in several places, it
may well evaluate the sub-expression once and then use the pre-
calculated value instead of calculating it all over again. This,
clearly, does violence to an order-of-operation notion based solely
on the expression syntax.
Or, what about strength reduction? If the compiler replaces a
multiplication inside a loop with an addition, in what order does
the now-vanished multiplication occur with respect to the other
operands in its containing expression? Does it not-occur before
or after the other operations? ("Last night I met upon the stair /
A little man who wasn't there. / He wasn't there again today. /
I wish, I *wish* he'd go away!")
Precedence and associativity are syntactical rules (or, friendly
summaries thereof) that tell the compiler what kind of parse tree to
build from a sequence of operators and operands. Semantic rules then
dictate the effect of evaluating the expression described by the parse
tree. Finally, the compiler generates code -- pretty much any kind
of code -- to produce that effect. But the compiler has great freedom
in how it decides to produce the effect: It may replace multiplications
with additions or shifts, it may evaluate a sub-expression long before
it seems to appear, it may intermix the evaluation of expressions in
separate statements, and so on. As long as it produces the required
outcome (including all observable side-effects in their proper order),
anything goes.