Hi Armin, hi Samuele, [Armin Rigo Tue, Nov 02, 2004 at 04:19:05PM +0000] > So LLVM comes again under the focus; we should really give it a serious try at > some point.
indeed. We may also give joeq (http://joeq.sourceforge.net) a look although development seems to be stalled. > There are clearly two point of views that we can take on RPython. The first > point of view is that RPython is a kind of nice syntax over a C- or Java-like > language (in this view integers are primitive, and type inference is used to > fill in the missing type declarations). The alternative is to see RPython as > semantically close to Python, and all the variables contain objects, but we > can obtain better performance via optimization. The current > annotation-and-Pyrex-or-Lisp approach follows the 1st approach, but I feel > like the 2nd one can give better results. Well, I guess you guessed :-) To me the pyrex approach was just a short-cut to produce what your new C-backend now produces directly. > Let me try to explore a few consequences of such a choice. A general critique > I have regarding a lot of research (including the paper you cited) is that the > techniques are flow-insensitive. the choice of the backend should not influence the flow/annotation analysis, should it? I guess i don't see the connection you seem to imply between these two parts of the translation process. > I'm not sure if it is a problem for the 1st > approach but it is for the 2nd one: the low-level flow graph of, say, "a+b" > is: > > if type(a) is int and type(b) is int: > x = make_int_object(add_long(a.ob_ival, b.ob_ival)) > else: > ... > > It is essential to follow the exact control path in this function, which tells > us that a and b only have a field 'ob_ival' to read when they are actually of > type int. Does this relate to a previous idea of generating two flow branches for the above if/else that would not get merged at the next point after the if/else? IIRC, we currently merge the "framestates" right after the if/else. cheers, holger _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
