Re: Compiler writers will love this language

genew@mail.ocis.net (Gene Wirchenko) wrote
> ericmuttta@email.com (Eric) wrote:
>
> [snip]
>
> >I have often wondered how specifying evaluation order impacts
> >implementation. The arguments I have heard for it are:
> >
> >- it allows consistency between different compilers hence allowing
> >code portability between compilers
> >
> >- it allows one to take advantage of evaluation order in expressions
> >
> >The second one sounds dubious at first but thinking about it, we
> >always rely on our code executing from top to bottom and write the
> >code so its dependant on that execution order. So then, is it
> >unresonable to specify that evaluation order is left-to-right (or
> >vice-versa)? If so, what are the arguments for leaving the order
> >undefined? (I have heard something related to efficiency and register
> >allocation during procedure invocations, but no explanation was
> >given).
>
> Reversing that, you can take advantage of evaluation order. It


> might be possible to optimise out constants by reordering evaluation:
>
> #define OFFSET1 5
> #define OFFSET2 15
> ...
> ... someint + OFFSET1 + OFFSET2 ...
>
> The natural order for most programmers appears to be variable
> followed by constant(s).


I see, if I define the order to be left-to-righ (or vice versa), the
compiler can perform "constant folding" and convert the above as
follows:


                someint + 5 + 15 --> someint + 20


If programmers stuck to such ordering of constants and variables, the
compiler doesnt need much effort to do the above optimisation.
However, I would imagine that a compiler doing any kind of reordering
in the first place, could handle something like this:


                OFFSET1 + someint + OFFSET2


just as easily, no? I'm still doing my A B C's of compiler writing so
I haven't gotten there yet, but I do know an extra degree of
"intelligence" is required on the compiler's part to handle that one.
It has to "figure out" that addition is commutative and hence my
version of the expression is equivalent to your version of the
expression. This means it can safely reorder the terms of the
expression and "fold" the constants into the single value "20", then
add that to someint.


Cheers, E.

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