micropython Code
A fast prototype implementation of a small subset of Python in C.
Status: Abandoned
Brought to you by:
blaisorblade
Menu
▾
▴
Tree [b60e08] default tip / History
Sigurd Meldgaard
Read Me
== 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.
