Class 33: Special topic: Interpreting IRTs
Held Wednesday, November 25, 1998
- 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
- Jamal, Rachel, Dave, Vivek, and
Ryan will discuss Pipelining. The will talk for the second
half of class.
- Coming Friday, December 11, 1998
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.
- 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
- It might also be reasonable to translate to IRT form for more
- 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
- 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
- A test of skill.
- 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.
- Suppose we wanted to compile to a simple assembly code (e.g., the
``straight-line'' IRTs that I've suggested) and interpret that
- 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).
- get the instruction corresponding to the program counter
- increment the program counter
- 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 ...
- Created Friday, November 20, as a blank outline.
Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.
Source text last modified Wed Nov 25 12:58:29 1998.
This page generated on Wed Nov 25 13:00:31 1998 by SiteWeaver.
Contact our webmaster at email@example.com