With the labeling algorithm described above it is not very difficult to compile if statements. After the code for the expression representing the condition of the if has been generated, the ifeq instruction is added, with no parameters. The parameters of this instruction should contain the offset for the jump, but as the index of the instruction to jump to (the first instruction following the code of the then-part) is not known, a label has to be set. For this we add an empty instruct structure containing the index of the ifeq instruction as its label. After the code of the then-part has been generated (remember, code is inserted before any label), there are two possibilities: either the if statement is finished or there is an else-part.
If there is no else-part and the if statement is finished, all that has to be done is to resolve the label. The index of the instruction to jump to if the condition of the if statement evaluates to false is the index of the first instruction following the then-part. The index of this instruction is the same as the index of the first instruct structure in the list where the label field is not -1. This label contains the index of the ifeq instruction, the instruction to jump from. Now the index contained in the label is subtracted from the index of the structure holding the label. A parameterlist is constructed from the resulting offset and is added as the parameterlist of the instruction at the index contained in the label, the ifeq instruction. After this is done, the instruct structure holding the label is removed from the list, and the compiler can continue.
If there is an else-part in the if statement however, there is a slightly different scenario. If the condition of the if statement evaluates to true, the else-part has to be skipped after the code of the then-part has been executed. This means that there has to be a goto instruction at the end of the then-part and before the else-part, which causes a jump to the first instruction following the else-part. For this we add a goto instruction to the code with no parameters. This instruction is of course inserted before any label. The label it is inserted before has to be the label containing the index of the ifeq instruction. As the first instruction of the else-part is the instruction following the goto instruction, the label of the ifeq instruction can now be resolved and the instruct structure holding it removed, just as I described before. After this label is deleted, the label for the goto instruction can be added. If it would have been added before the label of the ifeq instruction has been deleted, things would have gone wrong. Every time a label is resolved and deleted, the first label in the list is taken; this would have been the label of the goto. So the label of the goto instruction is added after the label of the ifeq instruction has been resolved and deleted, and the code for the else-part can be generated. After all the code for the else-part has been generated, the label for the goto can be resolved and deleted the same way as with the ifeq instruction before, and the if statement is finished.
By adding the labels in the correct order and adding all the instructions before the labels, the first label to be deleted is always the right one. This is also the case when if statements are nested. If the labeling is done the way I described above the labels are always added and deleted in the right order and at the right time.