SH
Delaying and reordering
PP
Intertwined with the code generation routines are two other,
interrelated processes.
The first, implemented by a routine called
II delay,
is based on the observation that
naive code generation for the expression
`a = b++' would produce
DS
mov b,r0
inc b
mov r0,a
DE
The point is that the table for postfix ++ has to preserve
the value of
II b
before incrementing it;
the general way to do this is to preserve its value in a register.
A cleverer scheme would generate
DS
mov b,a
inc b
DE
II Delay
is called for each expression input to
II rcexpr,
and it searches for postfix ++ and \-\-
operators.
If one is found applied to a variable,
the tree is patched to bypass the operator
and compiled as it stands;
then the increment or decrement itself is done.
The effect is as if `a = b; b++' had been written.
In this example, of course, the user himself could have done the same job,
but more complicated examples are easily constructed, for example
`switch (x++)'.
An essential restriction is that the condition codes not
be required.
It would be incorrect to compile
`if (a++) ...'
as
DS
tst a
inc a
beq ...
DE
because the `inc' destroys the required setting of the condition codes.
PP
Reordering is a similar sort of optimization.
Many cases which it detects are useful
mainly with register variables.
If
II r
is a register variable,
the expression `r = x+y' is best compiled
as
DS
mov x,r
add y,r
DE
but the codes tables would produce
DS
mov x,r0
add y,r0
mov r0,r
DE
which is in fact preferred if
II r
is not a register.
(If
II r
is not a register,
the
two sequences are the same size, but the
second is slightly faster.)
The scheme is to compile the expression as if it had been written
`r = x; r =+ y'.
The
II reorder
routine
is called with a pointer to each tree that
II rcexpr
is about to compile;
if it has the right characteristics,
the `r = x' tree is constructed and passed recursively
to
II rcexpr;
then the original tree is modified to read `r =+ y'
and the calling instance of
II rcexpr
compiles that instead.
Of course the whole business is itself recursive
so that more extended forms of the same phenomenon are
handled, like `r = x + y | z'.
PP
Care does have to be taken
to avoid `optimizing' an expression like `r = x + r'
into `r = x; r =+ r'.
It is required that the right operand of the expression on the right
of the `=' be a ', distinct from the register variable.
PP
The second case that
II reorder
handles is expressions of the form `r = X' used as a subexpression.
Again, the code out of the tables for
`x = r = y'
would be
DS
mov y,r0
mov r0,r
mov r0,x
DE
whereas if
II r
were a register it would be better to produce
DS
mov y,r
mov r,x
DE
When
II reorder
discovers that
a register variable is being assigned to
in a subexpression,
it calls
II rcexpr
recursively to
compile the subexpression, then fiddles the tree passed
to it so that the register variable itself appears
as the operand instead of the whole subexpression.
Here care has to be taken to avoid an infinite regress,
with
II rcexpr
and
II reorder
calling each other forever to handle assignments to registers.
PP
A third set of cases treated by
II reorder
comes up when any name, not necessarily a register,
occurs as a left operand of an assignment operator other than `='
or as an operand of prefix `++' or `\-\-'.
Unless condition-code tests are involved,
when a subexpression like `(a =+ b)' is seen,
the assignment is performed and the argument tree
modified so that
II a
is its operand;
effectively
`x + (y =+ z)' is compiled as `y =+ z; x + y'.
Similarly, prefix increment and decrement are pulled out
and performed first, then the remainder of the expression.
PP
Throughout code generation,
the expression optimizer is called whenever
II delay
or
II reorder
change the expression tree.
This allows some special cases to be found that otherwise
would not be seen.
