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
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
