Control Constructs

                              By
        
                      Jack W. Crenshaw, Ph.D.
        
                          19 August 1988                     
        
*****************************************************************
*                                                               *
*                        COPYRIGHT NOTICE                       *
*                                                               *
*   Copyright (C) 1988 Jack W. Crenshaw. All rights reserved.   *
*                                                               *
*****************************************************************

Introduction

In the first four instalments of this series, we've been concentrating on the parsing of maths expressions and assignment statements. In this instalment, we'll take off on a new and exciting tangent: that of parsing and translating control constructs such as IF statements.

This subject is dear to my heart, because it represents a turning point for me. I had been playing with the parsing of expressions, just as we have done in this series, but I still felt that I was a long way from being able to handle a complete language. After all, real languages have branches and loops and subroutines and all that. Perhaps you've shared some of the same thoughts. Awhile back, though, I had to produce control constructs for a structured assembler preprocessor I was writing. Imagine my surprise to discover that it was far easier than the expression parsing I had already been through. I remember thinking, "Hey! This is easy!" After we've finished this session, I'll bet you'll be thinking so, too.

The Plan

In what follows, we'll be starting over again with a bare cradle, and as we've done twice before now, we'll build things up one at a time. We'll also be retaining the concept of single-character tokens that has served us so well to date. This means that the "code" will look a little funny, with 'i' for IF, 'w' for WHILE, etc. But it helps us get the concepts down pat without fussing over lexical scanning. Fear not ... eventually we'll see something looking like "real" code.

I also don't want to have us get bogged down in dealing with statements other than branches, such as the assignment statements we've been working on. We've already demonstrated that we can handle them, so there's no point carrying them around as excess baggage during this exercise. So what I'll do instead is to use an anonymous statement, "other", to take the place of the non-control statements and serve as a place-holder for them. We have to generate some kind of object code for them (we're back into compiling, not interpretation), so for want of anything else I'll just echo the character input.

OK, then, starting with yet another copy of the cradle, saved as Branch01 let's define the procedure:

{ Recognize and translate an "Other" }
procedure Other;
begin
  EmitLn(GetName);
end;
 

Now include a call to it in the main program, thus:

{ Main Program }
begin
  Init;
  Other;
  ReadLn;
  ReadLn;
end.        

Run the program and see what you get. Not very exciting, is it? But hang in there, it's a start, and things will get better.

The first thing we need is the ability to deal with more than one statement, since a single-line branch is pretty limited. We did that in the last session on interpreting, but this time let's get a little more formal. Consider the following BNF:

     <program> ::= <block> END

     <block> ::= [ <statement> ]*

This says that, for our purposes here, a program is defined as a block, followed by an END statement. A block, in turn, consists of zero or more statements. We only have one kind of statement, so far.

What signals the end of a block? It's simply any construct that isn't an "other" statement. For now, that means only the END statement.

Armed with these ideas, we can proceed to build up our parser. The code of the procedure for the program we are compiling (called DoProgram so that the Pascal compiler will not complain) is:

{ Parse and translate a program }
procedure DoProgram;
begin
  Block;
  if Look <> 'e' then 
    Expected('End');
  WriteLn('//End of generated code');
end;
      

PPS: Our in-line assembly code will be copied into a test program and does not need an end statement but we output a comment marking the end of the program. This can be changed if the output is for the MASM assembler or if we decide to output an entire Pascal test program containing the block of in-line assembler code.

The code for Block is:

{ Recognize and translate a statement block }
procedure Block;
begin
  while not(Look in ['e']) do
    begin
      Other;
    end;
end;  

From the form of the procedure, you just know we're going to be adding to it in a bit!

OK, enter these routines into your program and change the main program to
{ Main program }
begin
  Init;
  DoProgram;
  ReadLn;
  ReadLn;
end.  
Now try it and see how it works. Well, it's still not much, but we're getting closer.

Some Groundwork

Before we begin to define the various control constructs, we need to lay a bit more groundwork. First, a word of warning: I won't be using the same syntax for these constructs as you're familiar with from Pascal or C. For example, the Pascal syntax for an IF is:
     IF <condition> THEN <statement>  
(where the statement, of course, may be compound).

The C version is similar:

     IF ( <condition> ) <statement>  

Instead, I'll be using something that looks more like Ada:

     IF <condition> <block> ENDIF  

In other words, the IF construct has a specific termination symbol. This avoids the dangling-else of Pascal and C and also precludes the need for the brackets {} or begin-end. The syntax I'm showing you here, in fact, is that of the language KISS that I'll be detailing in later instalments. The other constructs will also be slightly different. That shouldn't be a real problem for you. Once you see how it's done, you'll realize that it really doesn't matter so much which specific syntax is involved. Once the syntax is defined, turning it into code is straightforward.

Now, all of the constructs we'll be dealing with here involve transfer of control, which at the assembler-language level means conditional and/or unconditional branches. For example, the simple IF statement

     IF <condition> A ENDIF B ....       

must get translated into

          Branch if NOT condition to L
          A
     L:   B
        ...

It's clear, then, that we're going to need some more procedures to help us deal with these branches. I've defined two of them below. Procedure NewLabel generates unique labels. This is done via the simple expedient of calling every label '@Lnn', where nn is a label number starting from zero. Labels for in-line assembler must begin with '@'. Procedure PostLabel just outputs the labels at the proper place.

Here are the two routines:

{ Generate a unique label }
function NewLabel : string;
var 
  S : string;
begin
  Str(LCount, S);
  NewLabel := '@L' + S;
  Inc(LCount);
end;

{ Post a label To output }
procedure PostLabel(L : string);
begin
  WriteLn(L, ':');
end;
Notice that we've added a new global variable, LCount, so you need to change the var declarations at the top of the program to look like this:
var
  Look : char;              { Lookahead Character }
  Lcount : integer;         { Label Counter }
Also, add the following extra initialization to Init:
LCount := 0;  

(Don't forget that, or your labels can look really strange!)

At this point I'd also like to show you a new kind of notation. If you compare the form of the IF statement above with the assembler code that must be produced, you can see that there are certain actions associated with each of the keywords in the statement:

     IF:  First, get the condition and issue the code for it.
          Then, create a unique label and emit a branch if false.
      
     ENDIF: Emit the label.

These actions can be shown very concisely if we write the syntax this way:

     IF
     <condition>    { Condition;
                      L = NewLabel;
                      Emit(Branch False to L); }
     <block>
     ENDIF          { PostLabel(L) }

This is an example of syntax-directed translation. We've been doing it all along ... we've just never written it down this way before. The stuff in curly brackets represents the actions to be taken. The nice part about this representation is that it not only shows what we have to recognize, but also the actions we have to perform, and in which order. Once we have this syntax, the code almost writes itself.

About the only thing left to do is to be a bit more specific about what we mean by "Branch if false".

I'm assuming that there will be code executed for <condition> that will perform Boolean algebra and compute some result. It should also set the condition flags corresponding to that result. Now, the usual convention for a Boolean variable is to let 00000000 represent False and anything else (some use FFFFFFFF, some 00000001) represent True.

The condition flags are set whenever any data is calculated. If the data is a 00000000 (corresponding to a False condition, remember), the zero flag will be set. The code for "Branch on zero" is JE. (PPS: For "Branch" read "Jump"). So for our purposes here,

      JE   <=> Branch if False
      JNE  <=> Branch if True

It's the nature of the beast that most of the branches we see will be JE's ... we'll be branching around the code that's supposed to be executed when the condition is true.

The IF Statement

With that bit of explanation out of the way, we're finally ready to begin coding the IF-statement parser. In fact, we've almost already done it! As usual, I'll be using our single-character approach, with the character 'i' for IF, and 'e' for ENDIF (as well as END ... that dual nature causes no confusion). I'll also, for now, skip completely the character for the branch condition, which we still have to define.

The code for DoIf is:

{ Recognize and translate an IF construct }
procedure Block; forward;
procedure DoIf;
var 
  L : string;
begin
  Match('i');
  L := NewLabel;
  Condition;
  EmitLn('JE ' + L);
  Block;
  Match('e');
  PostLabel(L);
end;

Add this routine to your program, and change Block to reference it as follows:

{ Recognize and translate a statement block }
procedure Block;
begin
  while not (Look in ['e']) do 
    begin
      case Look of
        'i' : DoIf;
        'o' : Other;
      end;
  end;
end;  

PPS: This will be changed later with an else added to the case statement to allow characters other than 'O' to be output.

Notice the reference to procedure Condition. Eventually, we'll write a routine that can parse and translate any Boolean condition we care to give it. But that's a whole instalment by itself (the next one, in fact). For now, let's just make it a dummy that emits some text. Write the following routine:

{ Parse and translate a Boolean condition }
{ This version is a dummy }
procedure Condition;
begin
  EmitLn('<condition>');
end;
      

PPS: The condition may be simple or complex but will always evaluate to True (-1) or False (0). The code for implementing the condition will ensure that the zero flag is set for a False condition and cleared for True. The JE operation (equivalent to the JZ operation) performs a jump when the zero flag is set. (We usually see JE immediately after a compare statement, and we must remember that here it will correctly code for the required "Jump if False").

Insert this procedure in your program just before DoIf. Now run the program. Try a string like

oiooeoooe

As you can see, the parser seems to recognize the construct and inserts the object code at the right places. Now try a set of nested IF's, like

oioioooeoee

It's starting to look real, eh?

Now that we have the general idea (and the tools such as the notation and the procedures NewLabel and PostLabel), it's a piece of cake to extend the parser to include other constructs. The first (and also one of the trickiest) is to add the ELSE clause to IF. The BNF is
     IF <condition> <block> [ ELSE <block>] ENDIF        

The tricky part arises simply because there is an optional part, which doesn't occur in the other constructs.

The corresponding output code should be
          <condition>
          JE L1
          <block>
          JMP L2
     L1:  <block>
     L2:  ...
This leads us to the following syntax-directed translation:
     IF
     <condition>    { L1 = NewLabel;
                      L2 = NewLabel;
                      Emit(JE L1) }
     <block>
     ELSE           { Emit(JMP L2);
                      PostLabel(L1) }
     <block>
     ENDIF          { PostLabel(L2) }
Comparing this with the case for an ELSE-less IF gives us a clue as to how to handle both situations. The code below does it. (Note that I use an 'l' for the ELSE, since 'e' is otherwise occupied):
{ Recognize and translate an IF construct }
procedure Block; forward;
procedure DoIf;
var 
  L1, L2: string;
begin
  Match('i');
  Condition;
  L1 := NewLabel;
  L2 := L1;
  EmitLn('JE ' + L1);
  Block;
  if Look = 'l' then 
    begin
      Match('l');
      L2 := NewLabel;
      EmitLn('JMP ' + L2);
      PostLabel(L1);
      Block;
    end;
  Match('e');
  PostLabel(L2);
end;
Change the condition in Block to
while not (Look in ['e', 'l']) do  

There you have it. A complete IF parser/translator, in 19 lines of code.

Give it a try now. Try something like

          oiooloeoe

Did it work? Now, just to be sure we haven't broken the ELSE-less case, try

          oiooeoe

Now try some nested IF's. Try anything you like, including some badly formed statements. Just remember that 'e' is not a legal "other" statement.

Save the program as Branch02 in preparation for the iteration constructs.

The WHILE Statement

The next type of statement should be easy, since we already have the process down pat. The syntax I've chosen for the WHILE statement is

      WHILE <condition> <block> ENDWHILE  

I know, I know, we don't really need separate kinds of terminators for each construct ... you can see that by the fact that in our one-character version, 'e' is used for all of them. But I also remember many debugging sessions in Pascal, trying to track down a wayward END that the compiler obviously thought I meant to put somewhere else. It's been my experience that specific and unique keywords, although they add to the vocabulary of the language, give a bit of error-checking that is worth the extra work for the compiler writer.

Now, consider what the WHILE should be translated into. It should be:

     L1:  <condition>
          JE @L2
          <block>
          JMP @L1
     L2:        

As before, comparing the two representations gives us the actions needed at each point.

     WHILE          { L1 = NewLabel;
                      PostLabel(L1) }
     <condition>    { Emit(JE L2) }
     <block>
     ENDWHILE       { Emit(JMP L1);
                      PostLabel(L2) }  

The code follows immediately from the syntax:

{ Parse and translate a WHILE statement }
procedure DoWhile;
var 
  L1, L2: string;
begin
  Match('w');
  L1 := NewLabel;
  L2 := NewLabel;
  PostLabel(L1);
  Condition;
  EmitLn('JE ' + L2);
  Block;
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);
end;
  

Since we've got a new statement, we have to add a call to it within procedure Block:

{ Recognize and translate a statement block }
procedure Block;
begin
  while not(Look in ['e', 'l']) do 
    begin
      case Look of
        'i' : DoIf;
        'w' : DoWhile;
      else 
        Other;
      end;
    end;
end;
      

No other changes are necessary.

PPS: Now input letters other than 'e', 'l', 'i' and 'w' should be output (in upper case).

OK, try the new program. Note that this time, the <condition> code is inside the upper label, which is just where we wanted it. Try some nested loops. Try some loops within IF's, and some IF's within loops. If you get a bit confused as to what you should type, don't be discouraged: you write bugs in other languages, too, don't you? It'll look a lot more meaningful when we get full keywords.

I hope by now that you're beginning to get the idea that this really is easy. All we have to do to accommodate a new construct is to work out the syntax-directed translation of it. The code almost falls out from there, and it doesn't affect any of the other routines. Once you've gotten the feel of the thing, you'll see that you can add new constructs about as fast as you can dream them up.

The Loop Statement

We could stop right here, and have a language that works. It's been shown many times that a high-order language with only two constructs, the IF and the WHILE, is sufficient to write structured code. But we're on a roll now, so let's richen up the repertoire a bit.

This construct is even easier, since it has no condition test at all ... it's an infinite loop. What's the point of such a loop? Not much, by itself, but later on we're going to add a BREAK command, that will give us a way out. This makes the language considerably richer than Pascal, which has no break, and also avoids the funny WHILE(1) or WHILE TRUE of C and Pascal.

The syntax is simply

     LOOP <block> ENDLOOP  

and the syntax-directed translation is:

     LOOP           { L = NewLabel;
                      PostLabel(L) }
     <block>
     ENDLOOP        { Emit(JMP L) }  

The corresponding code is shown below. Since I've already used 'l' for the ELSE, I've used the last letter, 'p', as the "keyword" this time.

procedure DoLoop;
var 
  L : string;
begin
  Match('p');
  L := NewLabel;
  PostLabel(L);
  Block;
  Match('e');
  EmitLn('JMP ' + L);
end;  

When you insert this routine, don't forget to add a line in Block to call it.

REPEAT-UNTIL

Here's one construct that I lifted right from Pascal. The syntax is
     REPEAT <block> UNTIL <condition>,        

and the syntax-directed translation is:

     REPEAT         { L = NewLabel;
                      PostLabel(L) }
     <block>
     UNTIL
     <condition>    { Emit(JE L) }  

As usual, the code falls out pretty easily:

{ Parse and translate a REPEAT statement }  
procedure DoRepeat;
var 
  L : string;
begin
  Match('r');
  L := NewLabel;
  PostLabel(L);
  Block;
  Match('u');
  Condition;
  EmitLn('JE ' + L);
end;  

As before, we have to add the call to DoRepeat within Block. This time, there's a difference, though. I decided to use 'r' for REPEAT (naturally), but I also decided to use 'u' for UNTIL. This means that the 'u' must be added to the set of characters in the while-test. These are the characters that signal an exit from the current block ... the "follow" characters, in compiler jargon.

{ Recognize and translate a statement block }
procedure Block;
begin
  while not(Look in ['e', 'l', 'u']) do 
    begin
      case Look of
        'i' : DoIf;
        'w' : DoWhile;
        'p' : DoLoop;
        'r' : DoRepeat;
      else 
        Other;
      end;
    end;
end;  

The FOR Loop

The FOR loop is a very handy one to have around, but it's a bear to translate. That's not so much because the construct itself is hard ... it's only a loop after all ... but simply because it's hard to implement in assembler language. Once the code is figured out, the translation is straightforward enough.

C fans love the FOR-loop of that language (and, in fact, it's easier to code), but I've chosen instead a syntax very much like the one from good ol' BASIC:

     FOR <ident> = <expr1> TO <expr2> <block> ENDFOR       

The translation of a FOR loop can be just about as difficult as you choose to make it, depending upon the way you decide to define the rules as to how to handle the limits. Does expr2 get evaluated every time through the loop, for example, or is it treated as a constant limit? Do you always go through the loop at least once, as in FORTRAN, or not? It gets simpler if you adopt the point of view that the construct is equivalent to:

     <ident> = <expr1>
     TEMP = <expr2>
     WHILE <ident> <= TEMP
     <block>
     ENDWHILE   

Notice that with this definition of the loop, <block> will not be executed at all if <expr1> is initially larger than <expr2>.

The loop counter is in memory (so that it can be accessed within the loop), and the upper limit is on the stack.

          <ident>             get name of loop counter into ident
          <expr1>             get initial value into EAX
          MOV ident, EAX      move initial value into ident
          DEC ident           predecrement it
          MOV EAX, finish     get upper limit into EAX
          PUSH EAX            save it on stack
      L1: INC ident           move saved value
          POP EAX             get upper limit from stack
          CMP ident, EAX      check for range
          JG L2               skip out if counter  > upper limit
          PUSH EAX            save upper limit on stack
//        <Block>
          JMP L1              loop for next pass
      L2:   

The parser routine is pretty easy now that we have the code:

{ Parse and translate a FOR statement }
procedure DoFor;
var 
  L1, L2 : string;
  Name: char;
begin
  Match('f');
  L1 := NewLabel;
  L2 := NewLabel;
  Name := GetName;
  Match('=');
  Expression;  
  EmitLn('MOV ' + Name + ', EAX');
  EmitLn('DEC ' + Name);  
  Expression;
  EmitLn('PUSH EAX');
  PostLabel(L1);
  EmitLn('INC ' + Name);
  EmitLn('POP EAX');
  EmitLn('CMP ' + Name + ', EAX');
  EmitLn('JG ' + L2);
  EmitLn('PUSH EAX');
  Block;
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);  
end;  

Since we don't have expressions in this parser, I used the same trick as for Condition, and wrote the routine

{ Parse and translate an expression }
{ This version is a dummy }
Procedure Expression;
begin
  EmitLn('<expr>');
end;  

Give it a try. Once again, don't forget to add the call in Block. Since we don't have any input for the dummy version of Expression, a typical input line would look something like

afi=bece

Well, it does generate a lot of code, doesn't it? But at least it's the right code.

The Do Statement

All this made me wish for a simpler version of the FOR loop. The reason for all the code above is the need to have the loop counter accessible as a variable within the loop. If all we need is a counting loop to make us go through something a specified number of times, but don't need access to the counter itself, there is a much easier solution. The Intel processor has a "decrement and branch nonzero" instruction (Loop) built in which is ideal for counting. For good measure, let's add this construct, too. This will be the last of our loop structures.

The syntax and its translation is:

{ Parse and translate a DO statement }
procedure DoDo;
var 
  L : string;
begin
  Match('d');
  L := NewLabel;
  Expression;
  EmitLn('PUSH ECX');
  EmitLn('MOV ECX, EAX');
  PostLabel(L);
  Block;
  Match('e');
  EmitLn('LOOP ' + L);
  EmitLn('POP ECX');
end;
 

I think you'll have to agree, that's a whole lot simpler than the classical FOR. Still, each construct has its place.

PPS: You might like to save a working version of your program now. There are several changes to accommodate the BREAK. If you get stuck in this tricky section, you can refer to the final program for Part V given in full at the end of the page.

The BREAK Statement

Earlier I promised you a BREAK statement to accompany LOOP. This is one I'm sort of proud of. On the face of it a BREAK seems really tricky. My first approach was to just use it as an extra terminator to Block, and split all the loops into two parts, just as I did with the ELSE half of an IF. That turns out not to work, though, because the BREAK statement is almost certainly not going to show up at the same level as the loop itself. The most likely place for a BREAK is right after an IF, which would cause it to exit to the IF construct, not the enclosing loop. Wrong. The BREAK has to exit the inner LOOP, even if it's nested down into several levels of IFs.

My next thought was that I would just store away, in some global variable, the ending label of the innermost loop. That doesn't work either, because there may be a break from an inner loop followed by a break from an outer one. Storing the label for the inner loop would clobber the label for the outer one. So the global variable turned into a stack. Things were starting to get messy.

Then I decided to take my own advice. Remember in the last session when I pointed out how well the implicit stack of a recursive descent parser was serving our needs? I said that if you begin to see the need for an external stack you might be doing something wrong. Well, I was. It is indeed possible to let the recursion built into our parser take care of everything, and the solution is so simple that it's surprising.

The secret is to note that every BREAK statement has to occur within a block ... there's no place else for it to be. So all we have to do is to pass into Block the exit address of the innermost loop. Then it can pass the address to the routine that translates the break instruction. Since an IF statement doesn't change the loop level, procedure DoIf doesn't need to do anything except pass the label into its blocks (both of them). Since loops DO change the level, each loop construct simply ignores whatever label is above it and passes its own exit label along.

All this is easier to show you than it is to describe. I'll demonstrate with the easiest loop, which is LOOP:

{ Parse and translate a LOOP statement }
procedure DoLoop;
var 
  L1, L2 : string;
begin
  Match('p');
  L1 := NewLabel;
  L2 := NewLabel;
  PostLabel(L1);
  Block(L2);
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);
end;
  

Notice that DoLoop now has two labels, not just one. The second is to give the BREAK instruction a target to jump to. If there is no BREAK within the loop, we've wasted a label and cluttered up things a bit, but there's no harm done.

Note also that Block now has a parameter, which for loops will always be the exit address. The new version of Block is:

{ Recognize and translate a statement block }
procedure Block(L : string);
begin
  while not(Look in ['e', 'l', 'u']) do 
    begin
      case Look of
        'i' : DoIf(L);
        'w' : DoWhile;
        'p' : DoLoop;
        'r' : DoRepeat;
        'f' : DoFor;
        'd' : DoDo;
        'b' : DoBreak(L);
       else 
         Other;
      end;
    end;
end;    
  

Again, notice that all Block does with the label is to pass it into DoIf and DoBreak. The loop constructs don't need it, because they are going to pass their own label anyway.

The new version of DoIf is:

{ Recognize and translate an IF construct }
procedure Block(L : string); forward;
procedure DoIf(L : string);
var
  L1, L2 : string;
begin
  Match('i');
  Condition;
  L1 := NewLabel;
  L2 := L1;
  EmitLn('JE ' + L1);
  Block(L);
  if Look = 'l' then
    begin
      Match('l');
      L2 := NewLabel;
      EmitLn('JMP ' + L2);
      PostLabel(L1);
      Block(L);
    end;
  Match('e');
  PostLabel(L2);
end;  

Here, the only thing that changes is the addition of the parameter to procedure Block. An IF statement doesn't change the loop nesting level, so DoIf just passes the label along. No matter how many levels of IF nesting we have, the same label will be used.

Now, remember that DoProgram also calls Block, so it now needs to pass it a label. An attempt to exit the outermost block is an error, so DoProgram passes a null label which is caught by DoBreak:

{ Recognize and translate a BREAK }
procedure DoBreak(L : string);
begin
  Match('b');
  if L <> '' then
    EmitLn('JMP ' + L)
  else 
    Abort('No loop to break from');
end;

{ Parse and translate a program }
procedure DoProgram;
begin
  Block('');
  if Look <> 'e' then
    Expected('End');
  EmitLn('//End of generated in-line assembler ')
end;        
      

That takes care of everything. Give it a try, see if you can "break" it <pun>. Careful, though. By this time we've used so many letters, it's hard to think of characters that aren't now representing reserved words. Remember: before you try the program, you're going to have to edit every occurrence of Block in the other loop constructs to include the new parameter. Do it just like I did for DoLoop.

PPS: You may need to add a second label in some constructs.

At this point we have created a number of control constructs ... a richer set, really, than that provided by almost any other programming language. And, except for the FOR loop, it was pretty easy to do. Even that one was tricky only because it's tricky in assembler language.

I'll conclude this session here. To wrap the thing up with a red ribbon, we really should have a go at having real keywords instead of these mickey-mouse single-character things. You've already seen that the extension to multi-character words is not difficult, but in this case it will make a big difference in the appearance of our input code. I'll save that little bit for the next instalment. In that instalment we'll also address Boolean expressions, so we can get rid of the dummy version of Condition that we've used here. See you then.

For reference purposes, here is the completed parser for this session:

program Branch02;
{$Apptype Console}
uses
  SysUtils;
const
  TAB = ^I;
var
  Look : char;              { Lookahead Character }
  Lcount : integer;         { Label Counter }

{ Read new character from input stream }
procedure GetChar;
begin
  Read(Look);
end;

{ Report an error }
procedure Error(s : string);
begin
  WriteLn;
  WriteLn(^G, 'Error: ', s, '.');
  ReadLn;
  ReadLn;
end;

{ Report error and halt }
procedure Abort(s : string);
begin
  Error(s);
  Halt;
end;

{ Report what was expected }
procedure Expected(s : string);
begin
  Abort(s + ' Expected');
end;

{ Match a specific input character }
procedure Match(x : char);
begin
  if Look = x then
    GetChar
  else
    Expected('''' + x + '''');
end;

{ Recognize an alpha character }
function IsAlpha(c : char) : boolean;
begin
  IsAlpha := upcase(c) in ['A'..'Z'];
end;

{ Recognize a decimal digit }
function IsDigit(c : char): boolean;
begin
  IsDigit := c in ['0' .. '9'];
end;

{ Recognize an alphanumeric }
function IsAlNum(c : char) : boolean;
begin
  IsAlNum := IsAlpha(c) or IsDigit(c);
end;

{ Get an identifier }
function GetName : char;
begin
  if not IsAlpha(Look) then
    Expected('Name');
  GetName := UpCase(Look);
  GetChar;
end;

{ Get a number }
function GetNum : char;
begin
  if not IsDigit(Look) then
    Expected('Integer');
  GetNum := Look;
  GetChar;
end;

{ Recognize an addop }
function IsAddop(c : char): boolean;
begin
  IsAddop := c in ['+', '-'];
end;

{ Output a string with tab }
procedure Emit(s : string);
begin
  Write(TAB, s);
end;

{ Output a string with tab and CRLF }
procedure EmitLn(s : string);
begin
  Emit(s);
  WriteLn;
end;

{ Initialize }
procedure Init;
begin
  LCount := 0;
  GetChar;
end;

{ Generate a unique label }
function NewLabel : string;
var
  S: string;
begin
  Str(LCount, S);
  NewLabel := '@L' + S;
  Inc(LCount);
end;

{ Post a label To output }
procedure PostLabel(L: string);
begin
  WriteLn(L, ':');
end;

{ Recognize and translate an "Other" }
procedure Other;
begin
  EmitLn(GetName);
end;

{ Parse and translate a Boolean condition }
{ This version is a dummy }
procedure Condition;
begin
  EmitLn('<condition>');
end;

{ Recognize and translate an IF construct }
procedure Block(L : string); forward;
procedure DoIf(L : string);
var
  L1, L2 : string;
begin
  Match('i');
  Condition;
  L1 := NewLabel;
  L2 := L1;
  EmitLn('JE ' + L1);
  Block(L2);
  if Look = 'l' then
    begin
      Match('l');
      L2 := NewLabel;
      EmitLn('JMP ' + L2);
      PostLabel(L1);
      Block(L);
    end;
  Match('e');
  PostLabel(L2);
end;

{ Parse and translate a WHILE statement }
procedure DoWhile;
var
  L1, L2 : string;
begin
  Match('w');
  L1 := NewLabel;
  L2 := NewLabel;
  PostLabel(L1);
  Condition;
  EmitLn('JE ' + L2);
  Block(L2);
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);
end;

{ Parse and translate a LOOP statement }
procedure DoLoop;
var
  L1, L2 : string;
begin
  Match('p');
  L1 := NewLabel;
  L2 := NewLabel;
  PostLabel(L1);
  Block(L2);
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);
end;

{ Parse and translate a REPEAT statement }
procedure DoRepeat;
var
  L1, L2 : string;
begin
  Match('r');
  L1 := NewLabel;
  L2 := NewLabel;
  PostLabel(L1);
  Block(L2);
  Match('u');
  Condition;
  EmitLn('JE ' + L1);
  PostLabel(L2);
end;

{ Parse and translate an expression
  This version is a dummy }
procedure Expression;
begin
  EmitLn('<expr>');
end;

{ Parse and translate a FOR statement }
procedure DoFor;
var
  L1, L2 : string;
  Name : char;
begin
  Match('f');
  L1 := NewLabel;
  L2 := NewLabel;
  Name := GetName;
  Match('=');
  Expression;
  EmitLn('MOV ' + Name + ', EAX');
  EmitLn('DEC ' + Name);
  Expression;
  EmitLn('PUSH EAX');
  PostLabel(L1);
  EmitLn('INC ' + Name);
  EmitLn('POP EAX');
  EmitLn('CMP ' + Name + ', EAX');
  EmitLn('JG ' + L2);
  EmitLn('PUSH EAX');
  Block(L2);
  Match('e');
  EmitLn('JMP ' + L1);
  PostLabel(L2);
end;

{ Parse and translate a DO statement }
procedure DoDo;
var
  L1, L2 : string;
begin
  Match('d');
  L1 := NewLabel;
  L2 := NewLabel;
  Expression;
  EmitLn('PUSH ECX');
  EmitLn('MOV ECX, EAX');
  PostLabel(L1);
  Block(L2);
  Match('e');        
  EmitLn('LOOP ' + L1);
  PostLabel(L2);
  EmitLn('POP ECX');
end;

{ Recognize and translate a BREAK }
procedure DoBreak(L : string);
begin
  Match('b');
  if L <> '' then
    EmitLn('JMP ' + L)
  else
    Abort('No loop to break from');
end;

{ Recognize and translate a statement block }
procedure Block(L : string);
begin
  while not(Look in ['e', 'l', 'u']) do
    begin
      case Look of
        'i' : DoIf(L);
        'w' : DoWhile;
        'p' : DoLoop;
        'r' : DoRepeat;
        'f' : DoFor;
        'd' : DoDo;
        'b' : DoBreak(L);
      else
        Other;
      end;
    end;
end;

{ Parse and translate a program }
procedure DoProgram;
begin
  Block('');
  if Look <> 'e' then
    Expected('End');
  WriteLn('//End of generated code')
end;

{ Main program }
begin
  Init;
  DoProgram;
  ReadLn;
  ReadLn;
end.
*****************************************************************
*                                                               *
*                        COPYRIGHT NOTICE                       *
*                                                               *
*   Copyright (C) 1988 Jack W. Crenshaw. All rights reserved.   *
*                                                               *
*****************************************************************
Programming - a skill for life!

PPS introduction to the sixteen chapters of Let's build a compiler! by Jack Crenshaw, adapted for output to Intel processors. Conversion of compiler to output ARM assembler for use on Raspberry Pi.