On Thu, 17 Feb 2005, Carl Friedrich Bolz wrote: > ... > The problem is not to transform RPython to SSA since the pypy-tools do all > the difficult work. I was talking about the implementation of Python's more > interesting types like lists and dictionaries. All the methods of these > types have to be implemented somehow, which I did from hand in LLVM > assembler at first. This is what I meant when I talked about 'pain' ;-). > > I still have no good solution for this. At the moment I do the following: > The methods of the list objects are implemented in C as arrays of pointers > to "object" and turned to LLVM code (by compiling and disassembling it). The > result is used as a kind of template: All the occurences of the pointers to > "object" are replaced by the type of the values the list is supposed to > hold. This sounds rather brittle but works quite well at the moment. > > I will probably run into limitations whith this later. For example if I > implement exceptions (which should not be too complicated using invoke and > unwind) I can't raise them from within the C code that produces the list > implementation. > ...
Previous attempts to generate C code simply have inlined the calls the Python VM would have made. I wonder if you aren't making things too difficult by chosing not to leverage more of the Python C API. In PyFront, I wanted to use type inference to move more of the data flow into native C types. This model of just generating C code that does what the Python VM would have done has other benefits. Namely, the exception handling was simple, even if it was done in a brute force fashion. Each Python C API call was checked for an exception and goto's were used to goto exception handling code when NULL was returned. Anyway, I look forward to looking at what's new here, and hopefully have another RPython straw man (and implementation) to pitch at the PyCon sprint. -Jon _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
