Class 33: Special topic: Interpreting IRTs

Held Wednesday, November 25, 1998

Handouts

• Notes on the final project
• An interpreter for ``straight line'' IRTs.

Notes

• Today, we'll be discussing interpreters, particularly an interpreter I've written (I hope) for ``straight line IRTs''.
• Coming Monday, November 30, 1998
  • Tony Stubblebine will discuss Perl Monday at lunchtime.
• Coming Tuesday, December 1, 1998
  • Clif Flynt, our potential visitor for next semester, will be visiting on Tuesday and part of Wednesday. He'll be giving a public talk Tuesday at 4:15 followed by pizza and chatting. Get extra credit for coming and commenting.
• Coming Wednesday, December 3, 1998
  • Clif Flynt will be teaching CS151 at 9 a.m. Come, make comments, and get extra credit.
• Coming Monday, December 7, 1998
  • Tony Stubblebine will be continuing to talk about Perl at lunchtime.
  • Hilary, Raphen, Omar, and Sarah S will discuss Compiling Object-Oriented Languages.
  • Everyone will have the joy of filling out evaluations for this course.
  • I will hand out the final. It will be due on the following Thursday.
• Coming Wednesday, December 9, 1998
  • Sarah L, Kevin, and Jack will discuss Garbage collection. They will talk for the first half of class.
  • Jamal, Rachel, Dave, Vivek, and Ryan will discuss Pipelining. The will talk for the second half of class.
• Coming Friday, December 11, 1998
  • The last class.

Introduction

Today we'll spend much of the class discussing how we might interpret some form of intermediate or assembly code. Our discussion will be based, in part, on the sample code I've developed. We will consider issues pertaining to interpretation and to the ways in which one might execute assembly code.

Interpreting Programs

• As you know, compilers provide just one mechanism for working with programs. It is also possible to interpret programs written in high-level languges (that is, execute them without converting them to another language).
• Some parts of interpretation are similar to those of compilation. For example, it is still likely that you will want to tokenize and parse the input program (and, therefore, build at least the abstract syntax tree).
  • It might also be reasonable to translate to IRT form for more general interpretation.
• In fact, some languages provide structure editors that permit you to build the parse tree on the fly.
• Why interpret rather than compile?
  • Interpretation requires less ``compile time'' than does compilation.
  • It may be possible to interpret partial programs (which is one of the reasons we use structure editors), stopping when we run out of program.
  • Interpretation can provide additional feedback (more robust error messages, better indication of where you are in the program, ...).
  • It may be easier to write interpreters than compilers (no worrying about the details of a particular architecture, possible to accomodate stranger flows of control like ``select one of the following ...'').
  • ...
• Why compile rather than interpret?
  • The resulting code is typically much faster.
  • Adding to an existing compiler suite may actually be easier than interpretation.
  • A test of skill.
  • ....

Interpreting Tiger's AST's

• How might we interpret Tiger's abstract syntax trees?
• As in the case of type checking, we'll have a special function that traverses the tree, doing things as it goes.
• When it hits declarations (functions, variables, or types), it enters information in an appopriate table.
• We'll look at a few examples in class.

Designing and interpreting a simple assembly code

• Suppose we wanted to compile to a simple assembly code (e.g., the ``straight-line'' IRTs that I've suggested) and interpret that assembly code.
• What are we really simulating?
  • Translation of assembly code to machine code.
  • Execution of machine code.
• We'll need to consider which parts we do when.
• Note that we'll also need to think about standard compiling issues, such as parsing the textual assembly code.
  • By choosing an appropriately simple syntax, it is possible and reasonable to ``hand code'' a parser.
• What does our architecture look like?
  • Memory will contain program and data. The size of memory should be fixed to simulate dealing with stack and heap.
  • A number of designated registers will be used for common information, such as the program counter.
• How does our interpreter work?
  • It reads the program in to memory. We might represent the program textually or as bits (in effect, translating to machine code). I've chosen to represent it textually.
  • It executes the program.
  • It (optionally) prints out some results.
• How does one execute a program?
  • Set the program counter to the address of the initial instruction (determined as we read the program into memory).
  • Repeatedly
    1. get the instruction corresponding to the program counter
    2. increment the program counter
    3. execute the instruction, potentially changing the program counter
• What variables will be need to store and update?
  • The registers of our simulated machine.
  • The memory of the simulated machine.
  • Possibly the association between labels and addresses.
• What issues should we consider when reading programs?
  • What do we do with comments? (Discard them.)
  • Do we permit user-defined variables? (No.)
  • What do we do with strings? (Store them in the appropriate format, so that one string instruction may take multiple spaces in memory.)
  • What do we do with labels? Add them to a label-to-address tabel.
• More to come ...

History

• Created Friday, November 20, as a blank outline.