Hi Ben, On Fri, May 13, 2005 at 10:19:42AM +0100, [EMAIL PROTECTED] wrote: > I was wondering what the exact reasoning behind the new low level code.
I am aware that more information about this would be useful... The primary reason is that the code templates in GenC have more or less been pushed to their limits. These templates are by far not the first attempt; GenC has known a number of iterations that all ended up in the trash because they were becoming too messy. The current GenC was more or less stalled in the middle of implementing lists and instances. The new approach feels for the first time like a clean solution. > Is it just there to replace the code templates that are in genc? or is there > a deeper reason? There is actually a deeper reason (more below)... > Already the code seems much more complicated than the > code templates (and seems to contain its own templates in rlist.p for > example). Will the new code be easily transferrable to other backends (e.g > llvm or java) or is it tied to the c stuff? Yes, the purpose is that all back-ends can implement only the low-level operations, and don't have to worry about the lists and dicts and instances of RPython. The code has become more complicated in the sense that it depends on other parts of PyPy again -- like the annotator. By itself, it is rather a kind of simplification. Note that rlist.py contains not templates but plain functions, which are annotated and translated like the rest of the input program. There are definitely obscure corners in rlist.py and rpython/typer.py, e.g. to implement variable-length operations like newlist. We've focused on these dark corners at the moment; writing a complete implementation of the list operations in rlist.py should definitely make it clearer. The "deeper purpose" is that templates of C code are only useful to generate C code -- so far it's obvious. But they are also limited to generating "normal" C code; you can't tweak them automatically to generate different kinds of C code. For example, if a C template contains a for loop, the generated code will contain the same for loop. But if we want, say, to generate C code that uses Stackless-like continuation-passing, then we can't write C for loops directly; we have to tweak them a bit. This kind of tweaking is easy if the input is a flow graph containing low-level operations only, but you can't tweak C code templates. (Unless, that is, you parse the C code somehow; but that's the kind of discussion hinted at in the overview.txt file.) > Sorry if these are silly questions, I am just trying to get a better > understanding of why all this stuff is changing when you seemed so close > to getting more goals finished. You're welcome! I hope this helped to clear up some points. I know that generating a C version of PyPy is the most concrete and most visible short-term goal of PyPy. It's also our most important goal at the moment. But when it is reasonable to do so, we're trying to keep the longer-term goals in mind; they are, hopefully, the reason for most of the indirections we appear to take... A bientot, Armin _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
