plataforma - pypy vs python
¿PyPy se traduce a sí mismo? (2)
¿Estoy entendiendo esto? ¿El intérprete de PyPy se interpreta a sí mismo y luego se traduce?
Así que aquí está mi entendimiento actual:
- La cadena de herramientas de RPython implica la ejecución parcial del programa a traducir para obtener una especie de versión preprocesada para anotar y traducir.
- El intérprete de PyPy, que se ejecuta en la parte superior de CPython, se ejecuta para interpretarse a sí mismo, momento en el que entrega el control a su mitad RPython, ¿cuál realiza la traducción?
Si esto es cierto, entonces esta es una de las cosas más alucinantes que he visto.
Descargo de responsabilidad: no soy un experto en PyPy; en particular, no entiendo los detalles de la traducción de RPython, solo cito cosas que he leído antes. Para una publicación más específica sobre cómo puede funcionar la traducción de RPython, revisa esta answer .
La respuesta es, sí, puede (pero solo después de que se compiló utilizando CPython).
Descripción más larga:
Al principio, parece muy complejo y paradójico, pero una vez que lo entiendes, es fácil. Echa un vistazo a la respuesta en Wikipedia .
El arranque en el desarrollo de programas comenzó durante la década de 1950 cuando cada programa se construyó en papel en código decimal o en código binario, bit por bit (1s y 0s), porque no había lenguaje de computadora de alto nivel, ni compilador, ni ensamblador ni enlazador Un pequeño programa de ensamblador fue codificado a mano para una nueva computadora (por ejemplo, el IBM 650) que convirtió algunas instrucciones en código binario o decimal: A1. Este sencillo programa de ensamblador fue luego reescrito en su lenguaje de ensamblaje recién definido pero con extensiones que permitirían el uso de algunos mnemónicos adicionales para códigos de operación más complejos.
El proceso se llama arranque de software. Básicamente, usted construye una herramienta, digamos un compilador de C ++, en un lenguaje inferior que ya se ha hecho (todo en un punto tenía que ser codificado desde binario), digamos ASM. Ahora que tiene C ++ en existencia, ahora puede codificar un compilador de C ++ en C ++, luego usar el compilador ASM C ++ para compilar el nuevo. Una vez que haya compilado su nuevo compilador, ahora puede usarlo para compilarse.
Básicamente, cree la primera herramienta informática codificándola a mano, use ese intérprete para hacer otra mejor, y use esa para hacer una mejor, ... ¡Y eventualmente obtendrá todo el software complejo hoy! :)
Otro caso interesante, es el lenguaje CoffeeScript , que está escrito en ... CoffeeScript. (Aunque este caso de uso aún requiere el uso de un intérprete externo, a saber, Node.js)
El intérprete de PyPy, que se ejecuta en la parte superior de CPython, se ejecuta para interpretarse a sí mismo, momento en el que entrega el control a su mitad RPython, ¿cuál realiza la traducción?
Puede compilar PyPy usando un intérprete de PyPy ya compilado, o puede usar CPython para compilarlo en su lugar. Sin embargo, dado que PyPy tiene un JIT ahora, será más rápido compilar PyPy utilizando sí mismo, en lugar de CPython. ( PyPy ahora es más rápido que CPython en la mayoría de los casos)
El proceso de traducción de PyPy es en realidad mucho menos recursivo conceptualmente de lo que parece.
Realmente, todo lo que es es un programa de Python que procesa la función / clase / otros objetos de Python ( no el código fuente de Python) y genera el código C. Pero, por supuesto, no procesa cualquier objeto Python; solo puede manejar formularios particulares, que son lo que obtienes si escribes tu código para traducir en RPython.
Dado que la cadena de herramientas de traducción es un programa de Python, puede ejecutarlo sobre cualquier intérprete de Python, que obviamente incluye el intérprete de python de PyPy. Así que eso no es nada especial.
Ya que traduce objetos RPython, puede usarlo para traducir el intérprete de python de PyPy, que está escrito en RPython.
Pero no puede ejecutarlo en el propio marco de traducción, que no es RPython. Sólo el intérprete de Python de PyPy es RPython.
Las cosas solo se ponen interesantes porque el código RPython también es código Python (pero no al revés), y porque RPython nunca "existe realmente" en los archivos de origen, sino solo en la memoria dentro de un proceso Python operativo que necesariamente incluye otro código que no es RPython (no hay importaciones "RPYthon puras" o definiciones de funciones, por ejemplo, porque el traductor opera en funciones que ya se han definido e importado).
Recuerde que la cadena de herramientas de traducción opera en objetos de código Python en memoria. El modelo de ejecución de Python significa que no existen antes de que se haya ejecutado algún código de Python . Puede imaginar que el inicio del proceso de traducción se vea un poco así, si lo simplifica mucho:
from my_interpreter import main
from pypy import translate
translate(main)
Como todos sabemos, solo importar main va a ejecutar una gran cantidad de código Python, incluidos todos los demás módulos que importa my_interpreter . Pero el proceso de traducción comienza analizando la función objeto main ; nunca ve, y no le importa, el código que se ejecutó para crear main .
Una forma de pensar esto es que "programación en RPython" significa "escribir un programa Python que genera un programa RPython y luego lo alimenta al proceso de traducción". Es relativamente fácil de entender y es similar a la cantidad de compiladores que funcionan (por ejemplo, una forma de pensar en la programación en C es que básicamente está escribiendo un programa de preprocesador en C que genera un programa en C, que luego se envía al Compilador de c).
Las cosas solo se vuelven confusas en el caso de PyPy porque los 3 componentes (el programa Python que genera el programa RPython, el programa RPython y el proceso de traducción) se cargan en el mismo intérprete de Python . Esto significa que es bastante posible tener funciones que son RPython cuando se las llama con algunos argumentos y no cuando se las llama con otros argumentos, para llamar a funciones de ayuda desde el marco de traducción como parte de la generación de su programa RPython, y muchas otras cosas extrañas. Así que la situación se vuelve un tanto borrosa y no necesariamente se pueden dividir las líneas de origen limpiamente en "RPython para traducir", "Python generando mi programa RPython" y "entregar el programa RPython al marco de traducción".
El intérprete de PyPy, ejecutándose sobre CPython, se ejecuta para interpretarse parcialmente a sí mismo
Lo que creo que alude aquí es el uso que hace PyPy del espacio de objetos de flujo durante la traducción, para hacer una interpretación abstracta. Incluso esto no es tan loco y alucinante como parece al principio. Estoy mucho menos informado sobre esta parte de PyPy, pero como lo entiendo:
PyPy implementa todas las operaciones de un intérprete de Python al delegarlas en un "espacio de objetos", que contiene una implementación de todas las operaciones básicas integradas. Pero puede conectar diferentes espacios de objetos para obtener diferentes efectos, y siempre que implementen la misma interfaz de "espacio de objetos", el intérprete podrá "ejecutar" el código de Python.
Los objetos de código RPython que procesa la cadena de herramientas de traducción PyPy son códigos Python que pueden ser ejecutados por un intérprete. Así que PyPy reutiliza parte de su intérprete de Python como parte de la cadena de herramientas de traducción, al conectar el espacio de objetos de flujo. Al "ejecutar" código con este espacio de objetos, el intérprete no realiza realmente las operaciones del código, sino que produce gráficos de flujo, que son análogos a los tipos de representación intermedia utilizados por muchos otros compiladores; Es solo una simple representación del código manipulable por la máquina, para ser procesada. Así es como los objetos de código Python (R) normales se convierten en la entrada para el resto del proceso de traducción.
Ya que lo habitual que se traduce con el proceso de traducción es el intérprete Python de PyPy, de hecho se "interpreta" con el espacio de objetos de flujo. Pero todo lo que realmente significa es que tienes un programa Python que está procesando las funciones de Python, incluidas las que realizan el procesamiento. En sí mismo, no es más complicado que aplicar un decorador a sí mismo, o tener una envoltura de clase envuelve una instancia de sí mismo (o envuelve la clase en sí).
Um, eso se puso un poco inestable. Espero que ayude, de todos modos, y espero que no haya dicho nada incorrecto; por favor corrígeme si tengo.