Hi Samuele,
On Tue, Nov 02, 2004 at 06:09:57PM +0100, Samuele Pedroni wrote:
> In general I think that likely both 1 and 2 are worth pursuing, because
> of differences for target languages, characheteristic of produced code.
Makes sense. We must set priorities, and trying to go as far as possible with
the existing approach certainly looks like a good idea. This means that we
shouldn't put too many optimization efforts on the current C backend. I
suggest that the next goal would be to get something that works, even slowly,
and try to keep the Lisp backend up-to-date. I think that the type
annotations are not used much in the Lisp backend so far, but it should be
easy to generate type declarations. It might be a good way to get a "fast
enough" translation.
> I see, I just think that maybe we should try to get as far as possible
> with what we constructed so far, for example even ignoring structure
> inlining for the first approx. In Java, lisp etc is not that much a
> relevant problem because for example Java arrays carry a length anyway
> and are heap allocated.
Indeed, it looks like structure inlining ("option 2") is not really useful for
all target languages.
> One thing with approach 2 is that we need to rewrite a fair chunk of
> Python semantics themself in the compiler that way.
Yes, though these semantics have to be somewhere anyway; currently they are
distributed among the type inference, the backend itself, and in manually
written support code for the target language (i.e. the C macro file genc.h, or
the snippets of Lisp code included in gencl.py). Approach 2 would put them in
a central place, making the meta-programming Psyco-ish approach more explicit.
> I'm thinking that as long as we depend/use on CPython ref counting,
> ownership issues will crop up, they will likely not mix easely with
> trying to be clever with structures.
I don't think that reference counting is a major problem. The way I see
approach 2 so far is that we'd have basically two kinds of annotations for the
low-level graphs, SomeInlinedStructure and SomeHeapStructure. We'd use the
former as long as possible, i.e. as long as we can track all references to the
structure; and when we no longer can, we mark the structure's creation point
as "too complex" and reflow from there using SomeHeapStructure instead. Only
the latter would have reference counters and a CPython-compatible layout in
memory.
> OTOH I'm sure whether trying to go with full force with 2 is the best
> thing to get the first protototype interpreter running as an extension
> in CPython, especially thinking about ref counting.
I agree with you now for the reasons above, even if I think that the refcounts
are not a major issue (but maybe I'm overlooking something).
> Jython right now use the switch thing in some cases, but I suspect it is
> not JIT inlining friendly so a lot of inner classes are preferable.
Good to know. Well, I guess we'll have to try both and compare, anyway.
A bient�t,
Armin
_______________________________________________
[EMAIL PROTECTED]
http://codespeak.net/mailman/listinfo/pypy-dev
