Recent Articles

Sethi-Ullman algorithm

When generating code for arithmetic expressions, the compiler has to decide which is the best way to translate the expression in terms of number of instructions used as well as number of registers needed to evaluate a certain subtree (especially if free registers are scarce). The so called Sethi-Ullman algorithm (also known as Sethi-Ullman numbering) fulfills the property of producing code which needs the least number of instructions possible as well as the least number of storage references (under the assumption that at the most commutativity and associativity apply to the operators used, but laws like <math>a * b + a * c = a * (b + c)<math> do not hold). Please note that the algorithm succeeds as well if neither commutativity nor associativity hold for the expressions used, and therefore arithmetic transformations can not be applied.

Simple Sethi-Ullman algorithm

The simple Sethi-Ullman algorithm works as follows (for a load-store architecture):

1. Traverse the abstract syntax tree in pre- or postorder
   1. For every non-constant leaf node, assign a 1 (i.e. 1 register is needed to hold the variable/field/etc.).
   2. For every non-leaf node n, assign the number of registers needed to evaluate the respective subtrees of n. If the number of registers needed in the left subtree (l) are not equal to the number of registers needed in the right subtree (r), the number of registers needed for the current node n is max(l, r). If l == r, then the number of registers needed for the current node is l + 1.
2. Code emission
   1. If the number of registers needed to compute the left subtree of node n is bigger than the number of registers for the right subtree, then the left subtree is evaluated first (since it may be possible that the one more register needed by the right subtree to save the result makes the left subtree spill). If the right subtree needs more registers than the left subtree, the right subtree is evaluated first accordingly. If both subtrees need equal as much registers, then the order of evaluation is irrelevant.

Example

For an arithmetic expression <math>a = (b + c) * (d + 3)<math>, the abstract syntax tree looks like this:

To continue with the algorithm, we only need to examine the arithmetic expression <math>(b + c) * (d + 3)<math>, i.e. we only have to look at the right subtree of the assignment '=':

Now we start traversing the tree (in preorder for now), assigning the number of registers needed to evaluate each subtree (note that the last summand in the expression <math>(b + c) * (d + 3)<math> is a constant):

From this tree it can be seen that we need 2 registers to compute the left subtree of the '*', but only 1 register to compute the right subtree. Therefore we shall start to emit code for the left subtree first, because we might run into the situation that we only have 2 registers left to compute the whole expression. If we now computed the right subtree first (which only needs 1 register), we would then need a register to hold the result of the right subtree while computing the left subtree (which would still need 2 registers), therefore needing 3 registers concurrently. Computing the left subtree first needs 2 registers, but the result can be stored in 1, and since the right subtree needs only 1 register to compute, the evaluation of the epxression can do with only 2 registers left.

Advanced Sethi-Ullman algorithm

In an advanced version of the Sethi-Ullman algorithm, the arithmetic expressions are first transformed, exploiting the algebraic properties of the operators used.