Question

I'm reading pypy's document, which has a section called Translating the PyPy Python interpreter. But i don't understand what does the word translate mean. Is it the same as compile?

The document says:

First download a pre-built PyPy for your architecture which you will use to translate your Python interpreter.

Is the pre-built PyPy here refer to the source code? Because there is no pypy/goal directory in the binary I have downloaded. If so, there is something wrong with the document. It is misleading.

Is the pypy-c created in the translation the same thing as bin/pypy in the binary?

Was it helpful?

Solution

i don't understand what does the word translate mean. Is it the same as compile?

What "translation" means is described in detail in The RPython Toolchain. There's also some higher-level introductory information in the Coding Guide and FAQ.

Summarizing their summary:

  1. Compile and import the complete RPython program.
  2. Dynamically analyze the program and annotate it with flow graphs.
  3. Compile the flow graphs into lower-level flow graphs.
  4. Optimize the compiled flow graphs.
  5. Analyze the compiled and optimized flow graphs.
  6. Generate C source from the flow graphs and analysis.
  7. Compile and link the C source into a native executable.

So, step 1 uses the normal Python compiler, step 7 uses the normal C compiler (and linker), and steps 3 and 4 are similar to the kind of thing an optimizing compiler normally does. But calling the overall process "compilation" would be misleading. (Also, people would probably interpret it to mean something akin to what Shedskin does, which is definitely not right.)

Is the pypy-c created in the translation the same thing as bin/pypy in the binary?

What ends up in a binary distribution is basically the same as if you run the install process on the translation goal. So, yes, goal/pypy-c and bin/pypy are effectively the same thing.

Is the pre-built PyPy here refer to the source code?

No. It refers to a bin/pypy from a binary distribution. As the docs say, you can actually use any Python 2.6+, including CPython, or a goal/pypy-c left over from a previous build, etc. However, the translator will probably run fastest on the standard PyPy binary distribution, so that's what you should use unless you have a good reason to do otherwise.

OTHER TIPS

Let me give you what I can - PyPy is several things:

  1. A fast implementation of Python using a Just-In-Time compiler (written in RPython)
  2. The RPython JIT compiler compiler

When the docs talk about translating the interpreter they are talking about generating a JIT compiler for Python out of the RPython implementation of the Python compiler.

Python Compiler (Written in RPython)
    |--[RPython to JIT compiler compiler]--> 
        PyPy (JIT'ed Python Interpreter)

The key thing to note is that "compiler compiler" is not a typo. RPython is part of a toolchain used to generate JIT compilers. Rather than writing a compiler for your language and then writing a JIT layer for your compiler (which can be difficult and time consuming) instead you implement your language in RPython and the RPython translation toolchain writes you a JIT compiler for your language.

The easiest way to think about this is to imagine that the PyPy team hadn't written their own JIT compiler compiler. Imagine instead that Topaz (JIT Ruby) came first and that team had written a JIT compiler compiler in Ruby (we'll call it RRuby). The PyPy team would have then written the PyPy compiler in RRuby (instead, since PyPy came first, the Topaz team is implementing their JIT Ruby compiler in RPython).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top