[pypy-dev] FW: PyPy JIT and other languages

[Ben.Young at sungard.com]

Hi Carl Friedrich,

Thanks for the reply. The idea is that in most cases the AST will settle
down at some point (or could even be eagerly transformed), but there is
no guarantee that user nodes will do this if they don't want to. I think
a JIT will work 90% of the time. I considered rewriting it in c#  and
having nodes compile themselves to IL if they can prove no children can
do any manipulation, but I'd rather play with PyPy if possible!

I'm look to use the CLI backend anyway, as you get a nice standard
library built in anyway.

Thanks for the details on the rainbow interpreter. I'm looking forward
to the JIT being pushed forward again!

Cheers,
Ben



Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this email in error,
please notify the sender and delete this email from your system.  Thank
you. 

-----Original Message-----
From: Carl Friedrich Bolz [mailto:cfbolz at gmx.de] 
Sent: 06 February 2008 14:58
To: python at theyoungfamily.co.uk
Cc: pypy-dev at codespeak.net
Subject: Re: [pypy-dev] FW: PyPy JIT and other languages

Hi Ben,

Ben.Young at sungard.com wrote:
> I'm playing around with a bit of language design, and was wondering if

> the JIT is able to support languages that run by traversing an AST, 
> rather than by interpreting bytecode?

That is possible in principle, yes.

> The reason is, my toy language is 
> able to mutate itself at runtime, and so the AST that's running is
also 
> exposed at applevel.

So the AST can be changed by the program too? Or only be inspected? If 
the AST is changeable it would be harder to support. The JIT could do 
something like generating code for every version of the AST it sees or 
so. However, currently there is no mechanism for throwing away existing 
machine code, so if the code is changed and run very often, you get 
memory leaks.

You could do other stuff like generating machine code only as long as 
the AST is not changed and fall back to interpreting once it is. In the 
future we might add ways to remove generated code later (by giving the 
interpreter a way to trigger that or by removing code that is rarely 
executed).


> Also, can any of you give a 2 sentence description of what a rainbow 
> interpreter is? It looks like a very low level bytecode interpreter,
but 
> I'm sure it's more than that.

The rainbow interpreter is the component that will replace the 
timeshifter when it is done. The timeshifter transforms an interpreter 
into a compiler and is a rather complex component. The rainbow 
interpreter takes a different approach where the interpreter flow graphs

are interpreted to generate source code. The hope is that this 
interpreter is simpler than the transformation to allow experimentation 
with different approaches to figure out which things work.

Cheers,

Carl Friedrich