In any Translator Writing System which is used to translate from a high level language to assembly code, there is often a need to introduce labels or variables which do not appear in the original program and whose names must be different from the identifiers declared in the program. Consider, for example, the Algol statement:
if ALPHA ≥ a then BETA := GAMMA else DELTA := EPS ;
The assembly code generated must introduce labels to allow a conditional branch to be inserted, which will omit the execution of the first statement. The assembly code might take the form:
LOAD ALPHA BRNEG L1 LOAD GAMMA STORE BETA BR L2 L1: LOAD EPS STORE DELTA L2:
Introducing labels for a single statement is simple. However, for each conditional statement in the program, different labels need to be generated. Also, conditional statements may be nested so that any system of automatic label generation must cater for this.
These facilities can be implemented using the integer variables and arithmetic statements defined in Chapters 6 and 7. However, as this problem is one which often arises, TREE-META provides specific constructs for handling automatic label generation. Each call of a Code Rule in TREE-META (other than Simple Code Rules) has up to four unique labels associated with. it. On the 1900 implementation, these labels have names which are members of the set:
%L1 ,%L2 , %L3 , ....
It is a simple matter to change the common symbols %L to some other characters if that is required. These names are valid PLASYD identifiers and will be distinct from user-generated labels as the symbol % is rarely used as an alphabetic character. The string %L appears in the library routine %GNLB. If an alternative prefix is required, full details of how to modify the basic system are given in Chapter 9.
The labelling facility is implemented in TREE-META by associating four storage locations with each execution of a Code Rule. The four locations are initially set to zero. The first use of a particular label in a rule will allocate the next name in the %L set to this label. Subsequent uses of this label within the execution of the Code Rule will cause the same label name to be used.
To output a label name from a Code Rule, the symbol # is written followed by an integer between 1 and 4. These four symbols, #1, #2, #3 and #4, correspond to the four unique label names associated with this particular call of the Code Rule. For example:
ST[ ] => # 2 % #3 % #2 ;
would output three label names. Assuming that label names up to %L26 had already been allocated, a call of this Code Rule would produce:
%L27 %L28 %L27
Note that the second use of #2 generates the same label name. Each time the Code Rule ST is executed, two new label names will be output for #2 and #3. In the example, no label names are allocated to the unused labels #1 and #4.
It is possible for a Code Rule to call itself either directly or indirectly. In this case the allocation of label names becomes more complicated. The user must remember that labels are allocated the first time a new # item is encountered. Consider, for example:
.META PROG
PROG = ST * $ ( ';' ST * ) '.END' ;
ST = IFST / ASGNST ;
ASGNST = .ID '=' .ID :ASGN [2] ;
IFST = '.IF' .ID '≥ 0' '.THEN' ST '.ELSE' ST :IFF[3] ;
ASGN[-,-] => 'LOAD ' *2 ' ; , 'STORE ' *1 % ;
IFF[ -,-,-] => 'LOAD ' *1 ' ;' ' BRNEG ' #1 % *2
'BR ' #2 % #1 ':' % *3 #2 ':' % ;
.END
This allows both a simple assignment and a conditional statement to be input.
.IF A ≥ 0 .THEN
.IF B ≥ 0 .THEN C = D .ELSE E = F
.ELSE
J = K;
.END
would generate code:
LOAD A ; BRNEG %Ll LOAD B ; BRNEG %L2 LOAD D ; STORE C BR %L3 %L2: LOAD F ; STORE E %L3: BR %L4 %Ll: LOAD K ; STORE J %L4:
Note how the outer .IF statement is allocated labels %L1 and %L4 while the inner .IF is allocated %L2 and %L3.
Labels may be passed as arguments to other Code Rules. This allows a label name, allocated to one rule, to be used by another rule. The notation is best described by an example:
IFF[-,-,-] => 'LOAD ' *1 ' ;' ' BRNEG ' #1 % *2
'BR ' #2 % REST[#1,*3,#2] ;
REST[#4,-,#3] => #4 ':' % *2 #3 ':' % ;
These two rules are equivalent to the IFF rule in Section 5.2. The call of another Code Rule may contain labels as well as nodenames as arguments. If labels are specified in the call, then they must also be mentioned explicitly in the definition of the rule called. However, the labels need not be specified identically in both rules. In the example, the label name allocated to #1 in the IFF rule is passed to the REST rule as the label #4. Whenever #4 is used in this rule, the name associated with #1 in the IFF rule will be used (as long as REST is called from IFF).