Hi Kunshan, On 20 March 2015 at 04:16, Kunshan Wang <kunshan.w...@anu.edu.au> wrote: > (...) Others (including PyPy) build a whole new VM, > doing everything from scratch. There are many "high-performance VM" > projects like PyPy (LuaJIT, v8, JavaScriptCore, HHVM to name a few), but > the most important low-level parts (JIT, GC, ...) are not reused.
Nice to see a project that is similar to PyPy... even though you seem to have missed that point :-) PyPy is based on RPython, whose goal is also to provide a generic implementation substrate for any interpreter-based language, by providing a general GC and a meta-tracing JIT. For that reason I would not put PyPy in the same bag as LuaJIT, V8 and HHVM. There are a number of very different languages that already exist on top of the RPython architecture; PyPy (the Python implementation) is only the most well-known. Unlike Mu, the RPython toolchain was co-developed with PyPy, and so is a bit more specifically suited for languages that share some characteristics with Python (for example, multithreading is quite limited). Also, the separation between the two layers does not come with (e.g.) a nice intermediate file format produced from the source interpreter and fed to the RPython toolchain. It is certainly interesting to see what kind of results you'd get by feeding the "rtyped but not GC-transformed" instructions from RPython to the Mu platform. Again, I would recommend to start with smaller things than the whole PyPy. You can go about it in a test-driven way by starting from, say, the simple examples in rpython/translator/c/test/test_typed.py, and then pick the Prolog interpreter at https://bitbucket.org/cfbolz/pyrolog/ as a much-smaller first complete example. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
