[pypy-dev] gencli checkin

Antonio Cuni anto.cuni at gmail.com
Sun May 21 12:37:42 CEST 2006


Hi Maciek, hi all

Maciek Fijalkowski wrote:
> I've just checked in my changes to gencli which are essential for genjs 
> to use gencli. It does not brake any more tests (7 failed as was 
> before). I hope I don't get in conflict with your actual edits.

sorry for the very late response; I'm cc:ing to pypy-dev so that others 
can read.

I've read your changes, good work: I think that now the best thing to do
is to collect the modules used by both backends in a proper place, e.g.
a genoo package or so (better names are welcome :-).

Here are some comments on the modules that might be moved to genoo:

class_.py, function.py, record.py: they contain both generic code and 
gencli specific code (such as Class.get_base_class() and and 
Class._ctor() methods). We could put generic 'Class', 'Function' and 
'Record' class in genoo and subclass it in the backends.

cts.py: this is CLI specific, but each backend need a similar module: we
should at least put the interface specification in genoo, and possibly
some shared code.

database.py: there are both generic and specific parts, too. We should
provide a more flexible way to handle constants, and maybe we can
integrate it with the code from gensqueak that implements a sort of
priority queue for emitting things in the right order. IMHO each
backends should be able to decide whether to emit things in sequential
order (as gencli does, should be faster) or in "declaration order" (as
gensqueak and genjs2 need).

ilgenerator.py: same as cts.py.

oopspec.py: same as class_.py, function.py, record.py: some code can be 
shared, some need to be backend-specific.

rte.py: its goal is to automatically compile a DLL every time the source 
if modified: this could be useful for all backends that need to compile 
some runtime environment "offline".

sdk.py: very cli-specific.

metavm.py: the code here is of three types:

- generic code that can be used by all backends: the 
Generator/MicroInstrucion/InstructionList architecture is designed to be 
as much generic as possible, so it's not a problem to reuse it (note 
that the Generator interface is not very up-to-date, see Function.py).

- some classes are not cli-specific but they have been designed for 
emitting code on stack-based machines; I guess they are not very useful 
for genjs2, but they could be useful for a hypotetic genjava, for example.

- some code is very cli-specific, such as the _RuntimeNew class.

I wrote some ideas on how you can use and extend metavm for your goal, 
but I decided to move them to a fresh e-mail so we don't mix the two 
discussions.

At last we need a way to tell genoo where to find the code specific to 
each backend. I've seen that at the moment you decided to separately 
pass things such as CTS, Function, opcodes etc as arguments to GenCli 
constructor, but perhaps it would be better to collect them in a sort of 
'container' class and pass this all around; something like this:

class CliFunction: ...
class CliClass: ...
class CTS: ...
cli_opcodes = { ... }

class CliBackend:
   Function = CliFunction
   Class = CliClass
   TypeSystem = CTS
   opcodes = cli_opcodes
   ...

Better names other than CliBackend are welcome, too :-).

What do you think about this design? Valentino, Nikh, Seo and other that 
are working on high level backends: do you think that such a genoo could 
be useful for gensqueak and gencl, too?

ciao Anto



More information about the Pypy-dev mailing list