Kay Schluehr wrote: >>Speed isn't even the biggest problem when running PyPy on itself. >>PyPy still 'fakes' some objects, e.g. borrows them from the underlying >>Python. > > > Does it mean You create an RPython object that runs on top of CPython, > but is just an RPython facade wrapped around a CPython object?
yes. It means that there are objects that behave like they should in PyPy but are implemented by keeping creating a regular CPython instance of the object and delegating all calls on PyPy-level back to the CPython level. > So You have four kinds of Pythons: > > RPy - translateable into LL code > APy - non-translateable but interpretable by translated RPy > RPy* - non-translateable but consistent interface with RPy. Calls > APy* > APy* - not translateable and not interpreteable by translated RPy > > "Selfhosting" would imply vanishing RPy* and APy*. But the problem > seems to be that selfhosting must somehow be broken because the system > needs to interact with OS-dependend librarys. As long as You run the > system upon CPython the problem does not occur but once You drop it, a > kind of "extension objectspace" must be created which is translated > into code with nice interfacing properties. Or do You think that > RPython translations will be sufficient and another ext-objectspace is > just useless epi-cycling? Not exactly sure what you mean here. It's clear that we have to handle faked objects differently to get a stand-alone PyPy version. One possibility would be, that the RPython code calls certain functions which are implemented in Python (can be regular Python), that are not translated but replaced by a proper C function. For example we have a function intmask at the moment which takes a long and removes as many bits from it as neccessary to make it fit into an int again. This function is left out when translating, since in C an int can obviously not overflow to a long. Regards, Carl Friedrich -- http://mail.python.org/mailman/listinfo/python-list