Overview

== Introduction ==
This project is a proof-of-concept fast Python interpreter. It's really minimal.
Run "make" to try building on your system.

Three interpreters will be built, with different settings:
- interp_release: release mode, optimizations active.
- interp: verbose debugging mode, prints what it is doing at each opcode
  dispatch.
- interp_valgrind: same as interp, but some code is changed to shut up false
  positive warnings from Valgrind, or to give more real warnings (for instance,
  the gc does not clear the heap when it's emptied in this interpreter, to have
  a bigger chance to catch 'uninitialized memory' warnings).

Compile one of the included test programs with ./compiler.py, and run it with
./interp_release, ./interp or ./interp_valgrind.

For more info, see report/report.pdf.

== Portability ==
It has been tested on Ubuntu 7.10 (when it was first written), Ubuntu 9.10
(now) and Mac OS X (dunno which release). It supports only x86/x86_64 currently.
Requirements:
- GCC (it probably will not work well with ICC, becuase computed gotos are
  implemented in a different way).
- Python2.6. The provided examples worked with Python2.5 when they were
  developed, and support for the STORE_MAP opcode (not really used by version
  2.5) was added, allowing us to work under Python2.6; now we don't test any
  more against Python2.5 however.

== History ==
This project was born as a proof-of-concept for three features:
- indirect threading.
- using maps with transitions (à la V8) for Python (not really complete).
- writing a real GC for Python instead of using reference counting.
Some other intended features were:
- using code-copying without writing the interpreter in assembly (and this part
  of the project failed).
- being a multithreaded GIL-less fast interpreter (but right now it does not
  even support imports, or a builtin library).

== Planned supported features (for our term project) ==
We should try to cover all features which have a significant runtime cost, or
which are fundamental, and we should ignore the rest.

For instance, we don't plan to support:
- True/False (they are just wrappers around 1 and 0 which are displayed in a
  nicer way).
- long integers (just interfacing to GMP). We check for overflow however, to get
  the performance impact of that.
- built-in functions, although they would be easy to add.