[pypy-dev] Question about pypy

Maciej Fijalkowski fijall at gmail.com
Sun Dec 4 10:03:45 CET 2011


On Sat, Dec 3, 2011 at 10:33 PM, Alexander Golec
<alexgolecmailinglists at gmail.com> wrote:
> Erm, I'll revise that. The thesis of the talk is that rpython has to place restrictions on the use of types, and I leave discussing the annotator off to the term paper I'll be presenting. The purpose of this talk is a half-hour exposition of what we've been doing this semester, which basically makes it a promo for the term paper.
>
> Alex
>

RPython does more than that. It assumes that globals are constant for
example. The important part is that rpython puts enough restrictions
that global analysis of the entire system is possible.

Also an important point worth mentioning is that Python is a
meta-programming language for RPython, which makes RPython much better
than Java.

>
> On Dec 3, 2011, at 3:31 PM, Benjamin Peterson wrote:
>
>> 2011/12/3 Alexander Golec <alexgolecmailinglists at gmail.com>:
>>> Hi all,
>>>
>>> I'm a student at Columbia University, and I'm taking a graduate course with Alfred Aho, the author of the dragon book, on advanced compilers techniques. I've been researching the pypy project in general, and rpython in particular, and I'd like to ask you guys for some feedback on the current sketch of my presentation. Aho has mentioned on several occasions that he is very excited to receive my talk, and I'd like to get some feedback from you guys about it before I put it forward to him.
>>>
>>> So then, my talk will discuss rpython's approach to translation, and here is the current outline:
>>>
>>>  - Compiling python to C is easy: just inline the implementation of every opcode handler durr hurr hurr
>>>  - Ok, seriously, can you do it in a performant manner?
>>>  - Python has some semantics that make this difficult, in particular:
>>>    - opcodes are type-agnostic
>>>    - opcodes are high-level, they do high-level things with high-level arguments. eg. the BUILD_CLASS opcode
>>>    - opcodes include namespace operations
>>>  - This type-agnostic bit is the real tricky part because C requires all expressions to have a type, while python does not
>>>  - Vanilla cartesian product type inference doesn't really work because the number of types is undecidable
>>>  - rpython gets around this by imposing a restriction on dynamic type creation.
>>>  - The details of the annotator are omitted due to time constraints
>>
>> So you're not going to detail
>>
>>>
>>> So then, the crux of my talk is the type annotator.
>>
>> about the crux of your talk?
>>
>> --
>> Regards,
>> Benjamin
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev


More information about the pypy-dev mailing list