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