Re: [pypy-dev] interrupts, preemption, threads

2008-01-04 Thread Armin Rigo
Hi Daniel,

On Fri, Jan 04, 2008 at 01:46:40AM -0800, Daniel Farina wrote:
 I wasn't able to locate any of the keywords ['interrupt',
 'preemption', 'thread'] in the web documentation, so I come to
 the list to ask what is roughly the status of these things in the
 generated PyPy virtual machines on whatever applicable platforms.

We only have limited support for threads at the moment.  I think we have
no specific support for high-level backends (JVM, CLI).  On the
low-level backends (C, LLVM), you can use thread primitives to start
threads and use locks as you would do in C.  In addition there is
support in the translator for automatically inserting custom code before
and after every external function call.  We use this in PyPy's Python
interpreter: it uses a global interpreter lock (GIL), which is released
and reacquired around each external function call.  (This is similar to
CPython but we don't have to put the release/reacquire code everywhere
by hand.)

 - timeouts on arbitrary code fragments
 - writing a preemptive scheduler of closures
 - making use of two processors 
 - triggering garbage collections

We have no specific support for all this.  Multiple threads will run on
multiple processors just like in C.  Timeouts can be done in a
platform-specific way with signals.  For the rest, our custom garbage
collectors are not thread-safe, at least yet; only the Boehm collector
is, but its performance is not very good in multithreaded programs.


A bientot,

Armin.
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev


Re: [pypy-dev] [pypy-sprint] AVM2 / Tamarin backend at the sprint

2008-01-04 Thread Antonio Cuni
Toby Watson wrote:
 Hi Antonio,

Hi Toby,

 Thanks for the advice and pointers into the code.
 
 Would you say this is still a fair assessment of the tasks that have to 
 be done to target a new backend? : (pulled from PyPy[cli-backend])
 
 • map ootypesystem's types to CLI Common Type System's types;
 
 • map ootypesystem's low level operation to CLI instructions;
 
 • map Python exceptions to CLI exceptions;
 
 • write a code generator that translates a flow graph into a list of 
 CLI instructions;
 
 • write a class generator that translates ootypesystem classes into 
 CLI classes.
 
 Was this pre or post the refactoring you describe?

this list was written before the refactoring, but I think it's more or 
less still valid.

First of all, you need a strong understanding of both ootypesystem and 
the type system of the VM you want to targets: then you can think how to 
map the types; for CLI and JVM it was mostly straightforward, but maybe 
it wouldn't be so for AVM2, e.g. if it doesn't support classes in the 
same way ootypesystem expects.

After you have mapped types, mapping instructions would be just a matter 
of coding but it shouldn't be too hard.

The paragraph about exceptions is mostly historical; at least at the 
beginning, you shouldn't need to do anything special about exceptions as 
long as you keep the hierarchy of RPython exceptions separated from the 
hierarchy of the VM exceptions.

The cool thing is that the hardest point (code generator) have been 
already implemented in oosupport, and it's very easy to subclass it for 
targeting yet another VM.

If you want to have a closer look to how each point is implemented, here 
are some pointers in the code:

   * mapping types
   - for cli, it's cli/cts.py; the main entry-point is the function 
lltype_to_cts

   - for jvm, it's jvm/typesystem.py; however, the main entry-point 
is the function lltype_to_cts in jvm/database.py


   * mapping operations: see cli/opcodes.py and jvm/opcodes.py

   * code generator: the base class is in oosupport/function.py, 
subclassed in cli/function.py and jvm/nodes.py (class GraphFunction); 
the Function class knows how to deal with graphs, but it delegates the 
actual code generation to something specific to each backend; for cli, 
it's in cli/ilgenerator.py, for jvm it's the GraphFunction class itself.

   * class generator: cli/class_.py and the Class class in jvm/node.py

ciao Anto
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev