Ir al contenido

Diferencia entre revisiones de «Intérprete (informática)»

De Wikipedia, la enciclopedia libre
Contenido eliminado Contenido añadido
m Revertidos los cambios de 189.139.39.4 a la última edición de 201.203.5.110
Sin resumen de edición
Línea 1: Línea 1:
En [[ciencias de la computación]], '''intérprete''' o '''interpretador''' es una cutusa [[programa (computación)|programa informático]] capaz de analizar y ejecutar otros programas, escritos en un [[lenguaje de programación|lenguaje]] de [[lenguaje de alto nivel|alto nivel]]. Los intérpretes se diferencian de los [[compilador]]es en que mientras estos traducen un programa desde su descripción en un [[lenguaje de programación]] al [[código de máquina]] del sistema, los primeros (los intérpretes) sólo realizan la [[proceso de traducción de programas|traducción]] a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción.
Un '''lenguaje interpretado''' es un [[lenguaje de programación]] que está diseñado para ser ejecutado por medio de un [[intérprete informático|intérprete]], en contraste con los [[lenguaje compilado|lenguajes compilados]]. Teóricamente, cualquier [[lenguaje de programación|lenguaje]] puede ser [[compilador|compilado]] o ser interpretado, así que esta designación es aplicada puramente debido a la práctica de implementación común y no a alguna característica subyacente de un lenguaje en particular. Sin embargo, hay los lenguajes que son diseñados para ser intrínsecamente interpretativos, por lo tanto un [[compilador]] causarán una carencia de la eficacia. Muchos autores rechazan la clasificación de lenguajes de programación entre interpretados y compilados, considerando que el modo de ejecución (por medio de intérprete o de [[compilador]]) del [[programa de computadora|programa]] escrito en el lenguaje es independiente del propio lenguaje. A ciertos lenguajes interpretados también se les conoce como lenguajes de '''''[[guión (informática)|script]]'''''.


Usando un intérprete, un solo archivo fuente puede producir resultados iguales incluso en sistemas sumamente diferentes (ej. una [[computador personal|PC]] y un [[PlayStation 3]]). Usando un compilador, un solo archivo fuente puede producir resultados iguales solo si es compilado a distintos ejecutables específicos a cada sistema.
Muchos lenguajes han sido implementados usando tanto compiladores como intérpretes, incluyendo [[Lisp]], [[Lenguaje de programación Pascal|Pascal]], [[lenguaje C|C]], [[BASIC]], y [[Python]]. Mientras que [[Lenguaje de programación Java|Java]] es traducido a una forma que se destina a ser interpretada, la [[compilación justo a tiempo]] es frecuentemente usada para generar el [[código de máquina]]. Los lenguajes de [[Microsoft .NET]] compilan a una forma intermedia ([[Common Intermediate Language|CIL]]) la cual es entonces a menudo compilada en código de máquina nativo; sin embargo hay una [[máquina virtual]] capaz de interpretar el CIL. Muchas implementaciones Lisp pueden mezclar libremente código interpretado y compilado. Estas implementaciones también usan un compilador que puede traducir arbitrariamente código fuente en [[tiempo de ejecución]] (runtime) a código de máquina.


Los programas interpretados suelen ser más lentos que los compilados debido a la necesidad de traducir el programa mientras se ejecuta, pero a cambio son más flexibles como entornos de [[programación]] y [[depuración]] (lo que se traduce, por ejemplo, en una mayor facilidad para reemplazar partes enteras del programa o añadir módulos completamente nuevos), y permiten ofrecer al programa interpretado un entorno no dependiente de la máquina donde se ejecuta el intérprete, sino del propio intérprete (lo que se conoce comúnmente como [[máquina virtual]]).
== Antecedentes históricos del interpretado y compilado ==


Para mejorar el desempeño, algunas implementaciones de programación de lenguajes de programación pueden interpretar o compilar el código fuente original en una más compacta forma intermedia y después traducir eso al código de máquina (ej. [[Perl]], [[Python]], [[MATLAB]], y [[Ruby]]). Algunos aceptan los archivos fuente guardados en esta representación intermedia (ej. Python, [[UCSD Pascal]] y [[Lenguaje de programación Java|Java]]).
En los comienzos de la computación, el diseño del lenguaje fue fuertemente influenciado por la decisión de usar como modo de ejecución, la compilación o la interpretación. Por ejemplo, algunos lenguajes compilados requieren que los programas deban indicar explícitamente el [[tipo de dato]] de una [[Variable (programación)|variable]] en el momento en que sea declarada o al ser usada por primera vez. Por otro lado, algunos lenguajes interpretados toman ventaja de los aspectos dinámicos de la interpretación para hacer tales declaraciones innecesarias. Por ejemplo, [[SmallTalk]], el cual fue diseñado para ser interpretado en tiempo de ejecución, permite a objetos genéricos interactuar dinámicamente entre sí.


Comparando su actuación con la de un ser humano, un compilador equivale a un traductor profesional que, a partir de un texto, prepara otro independiente traducido a otra lengua, mientras que un intérprete corresponde al intérprete humano, que traduce de viva voz las palabras que oye, sin dejar constancia por escrito.
Inicialmente, los lenguajes interpretados eran compilados línea por línea; es decir, cada línea era compilada a medida que estaba a punto de ser ejecutada, y si un [[Bucle (programación)|loop]] o una [[subrutina]] hiciera que ciertas líneas se ejecutaran múltiples veces, ellas debían ser recompiladas repetidamente. Esto ha llegado a ser mucho menos común. La mayoría de los lenguajes interpretados usan una representación intermedia, que combina tanto la compilación como la interpretación. En este caso, un compilador puede producir una cierta forma representación intermedia del programa, como el [[bytecode]] o el [[código enhebrado]], que entonces es ejecutado por un [[intérprete (informática)|intérprete]] de bytecode. Los ejemplos incluyen [[Python]], y [[Lenguaje de programación Java|Java]]. Similarmente, [[Ruby]] utiliza un [[árbol de sintaxis abstracta]] como representación intermedia. La representación intermedia puede ser compilada de una vez por todas (como en Java), cada vez que se vaya a ejecutar (como en [[Perl]] o Ruby), o cada vez que un cambio en el [[código fuente]] es detectado antes de la ejecución (como en [[Python]]).


En la actualidad, uno de los entornos más comunes de uso de los intérpretes informáticos es [[Internet]], debido a la posibilidad que estos tienen de ejecutarse independientemente de la plataforma.
== Ventajas de los lenguajes interpretados ==


== Interpretadores de bytecode ==
Los lenguajes interpretados dan a los programas cierta flexibilidad adicional sobre los [[lenguaje compilado|lenguajes compilados]]. Algunas características que son más fáciles de implementar en intérpretes que en compiladores incluyen, pero no se limitan, a:


{{AP|Bytecode}}
* independencia de [[Plataforma (informática)|plataforma]] (por ejemplo el [[byte code]] de Java)
* [[Reflexión (informática)|reflexión]] y uso reflexivo del evaluador (ej. una función [[eval]] de primer orden)
* [[Tipo de dato|tipos]] dinámicos
* facilidad en la [[depuración]] (es más fácil obtener información del código fuente en lenguajes interpretados)
* pequeño tamaño del programa (puesto que los lenguajes interpretados tienen flexibilidad para elegir el [[conjunto de instrucciones|código de instrucción]])
* [[ámbito (programación|ámbito]] dinámico
* [[Recolector de basura|gestión de memoria automática]]


Hay un espectro de posibilidades entre la interpretación y la compilación, dependiendo de la cantidad de análisis realizados antes de que el programa sea ejecutado. Por ejemplo, el [[Emacs Lisp]] es compilado a [[bytecode]], que es una representación altamente comprimida y optimizada del [[código fuente]] del [[Lisp]], pero no es [[código de máquina]] (y por lo tanto no está atado a cualquier hardware particular). Este código "compilado" es entonces interpretado por un interpretador de bytecode (que está escrito en [[Lenguaje de programación C|C]]). En este caso, el código compilado es el código de máquina para una [[máquina virtual]], que no está implementada en el hardware, sino en el interpretador de bytecode. El mismo acercamiento es utilizado con el código [[Forth]] usado en sistemas [[Open Firmware]]: el lenguaje fuente es compilado en "código F" (un bytecode), que entonces es interpretado por una máquina virtual.
== Desventajas de los lenguajes interpretados ==


== Eficiencia ==
La ejecución del programa por medio de un intérprete es usualmente mucho menos eficiente que la ejecución de un programa compilado. No es [[eficiencia de algoritmos|eficiente en tiempo]] porque, o cada instrucción debe pasar por una interpretación en tiempo de ejecución, o como en más recientes implementaciones, el código tiene que ser compilado a una representación intermedia antes de cada ejecución. La máquina virtual es una solución parcial al problema de la eficiencia del tiempo pues la definición del lenguaje intermedio es mucha más cercana al [[lenguaje de máquina]] y por lo tanto más fácil de ser traducida en tiempo de ejecución. Otra desventaja es la necesidad de un intérprete en la máquina local para poder hacer la ejecución posible.


La desventaja principal de los interpretadores es que cuando se interpreta un programa, típicamente corre más lentamente que si hubiera sido compilado. La diferencia en velocidades puede ser minúscula o grande; a menudo un orden de magnitud y a veces más. Generalmente toma más tiempo correr un programa bajo un interpretador que correr el código compilado, pero puede tomar menos tiempo para interpretarlo que el tiempo total requerido para compilarlo y ejecutarlo. Esto es especialmente importante si se está haciendo y probando un código prototipo cuando un ciclo de editar, interpretar y depurar del interpretador, a menudo puede ser mucho más corto que el ciclo de editar, compilar, ejecutar y depurar del compilador.
==Lenguajes interpretados de uso común==


La interpretación de código es más lenta que la ejecución de código compilado porque el interpretador debe analizar cada sentencia en el programa cada vez que es ejecutada y entonces realizar la acción deseada, mientras que el código compilado solo realiza la acción dentro de un determinado contexto fijo por la compilación. Este análisis en [[tiempo de ejecución]] se conoce como "sobrecarga interpretativa". En un interpretador, el acceso a las variables es también más lento porque el mapeo de identificadores hacia las localizaciones de almacenamiento debe hacerse repetidamente en tiempo de ejecución en vez de en el [[tiempo de compilación]]. Hay varios compromisos entre la velocidad de desarrollo al usar un interpretador y la velocidad de ejecución al usar un compilador. Algunos sistemas (ej., algunos [[LISP]]s) permiten al código interpretado y al compilado llamarse el uno al otro y compartir variables. Esto significa que una vez que una rutina ha sido probada y depurada bajo el interpretador puede ser compilada y por lo tanto beneficiarse de una ejecución más rápida mientras que otras rutinas están siendo desarrolladas. Muchos interpretadores no ejecutan el código fuente tal y como está sino que lo convierten en una forma interna más compacta. Por ejemplo, algunos interpretadores [[BASIC]] reemplazan [[palabra clave|palabras clave]] (keywords) con tokens de un simple [[byte]] que pueden ser usados para encontrar la instrucción en una [[tabla de saltos]]. Un interpretador puede bien usar el mismo [[analizador lexicográfico]] y el [[analizador sintáctico]] (parser) que el compilador y entonces interpretar el [[árbol de sintaxis abstracta]] resultante.
Los lenguajes que suelen ser interpretados más famosos en la actualidad son (en orden alfabético):


== Interpretadores de árbol de sintáxis abstracta ==
*[[ActionScript]]

*[[Active_Server_Pages|ASP]] (hasta la versión 3)
En el espectro entre la interpretación y la compilación, otro acercamiento está transformando el código fuente en un [[árbol de sintaxis abstracta]] optimizado (AST), y después procediendo a ejecutar el programa siguiendo esta estructura [[Árbol (estructura de datos)|arborescente]].<ref>[http://lambda-the-ultimate.org/node/716 AST intermediate representations], Lambda the Ultimate forum</ref> En este acercamiento cada sentencia necesita ser analizada (parsed) solo una vez. Como una ventaja sobre el bytecode, el AST mantiene la estructura y las relaciones globales del programa entre las sentencias (que se pierden en una representación de bytecode), y proporciona una representación más compacta.<ref>[http://citeseer.ist.psu.edu/article/kistler97treebased.html A Tree-Based Alternative to Java Byte-Codes], Thomas Kistler, Michael Franz</ref>
*[[Bash]]

*[[Basic4GL]] (Basic para OpenGL. Permite generar ejecutables Windows completos)
Así, el AST se ha propuesto como un mejor formato intermedio para los [[compilador justo a tiempo|compiladores justo a tiempo]] que el bytecode. También, permite realizar un mejor análisis durante tiempo de ejecución. Un interpretador Java basado en AST ha demostrado ser más rápido que un interpretador similar basado en bytecode,<ref>[http://central.kaserver5.org/Kasoft/Typeset/JavaTree/index.html Trees Versus Bytes], BComp Honours thesis by Kade Hansson</ref> gracias a las más poderosas optimizaciones permitidas al tener la estructura completa del programa, así como [[Tipo de dato|tipos de datos]] de alto nivel, disponibles durante la ejecución.
*[[BeanShell]] (Java en lenguaje de Scripts)

*[[Inform]]
== Compilación justo a tiempo ==
*[[IO]] (es un lenguaje reciente -2002-)

*[[JavaScript]] (todas las plataformas)
Para desdibujar más la distinción entre los interpretadores, los interpretadores de bytecode y la compilación, está la [[compilación justo a tiempo]] (o JIT), una técnica en la cual la representación intermedia es compilada a [[código de máquina]] nativo en tiempo de ejecución. Esto confiere la eficiencia de ejecutar el código nativo, al costo de tiempo de inicio y de un uso creciente de la memoria cuando el bytecode o el AST es compilado por primera vez. La [[optimización adaptativa]] es una técnica complementaria en la cual el interpretador hace un análisis de desempeño del programa que está corriendo (profiling) y compila sus partes más frecuentemente ejecutadas a código nativo. Ambas técnicas tienen algunas décadas, apareciendo en lenguajes tales como [[Smalltalk]] en los años 1980.
*[[Lenguaje de programación Logo|Logo]] ([[Linux]], [[Windows]] y [[Mac]])

*[[Lenguaje de programación R]]
En años recientes, la compilación justo a tiempo ha ganado la atención de la mayoría de los implementadores de lenguajes de programación, con [[Lenguaje de programación Java|Java]], [[Python]], y el [[Microsoft]] [[.NET Framework]] todos ahora incluyendo JITs.
*[[Lisp]]

*[[Lua]]
== Interpretador de tarjeta perforada ==
*[[Lush]] (Lisp para gráficos [[Linux]])

*[[NWNScript]] (empleado en el [[videojuego]] ''[[Neverwinter Nights]]'' y ''[[Neverwinter Nights 2]]'')
El término "interpretador" frecuentemente se refería a una pieza de [[equipo de registro de unidad]] que podía leer [[tarjeta perforada|tarjetas perforadas]] e imprimir los caracteres en la tarjeta en una forma que podía ser leída por humanos. El interpretador Numérico del [[IBM 550]] y el Interpretador Alfabético del [[IBM 557]] son ejemplos típicos a partir de 1930 y 1954, respectivamente.
*[[Perl]] (todas las plataformas)

== Ejemplos ==
Algunos ejemplos de [[lenguaje interpretado|lenguajes que son normalmente interpretados en vez de compilados]] son:

*[[Perl]]
*[[PHP]]
*[[PHP]]
*[[Lenguaje de programación Java|Java]]
*[[Pike]] (es el más rápido de todos, al estar escrito en gran parte en código nativo)
*[[Javascript]]
*[[Python]] (todas las plataformas)
*[[Logo (Lenguaje de programación)|Logo]]
*[[REXX]] y variantes como [[Object REXX]] (todas las plataformas, en especial: [[OS/2]] / [[AmigaOS]])
*[[Active Server Pages|ASP]] (hasta la versión 3)
*[[Ruby]]
*[[Tcl]]
*[[Python]]
* C#
*[[VBScript]] (Microsoft [[Windows]])
*J#
*ASP


== Notas y referencias ==
==Véase también==

<references/>

== Véase también ==

* [[Lenguaje de programación]]
* [[Proceso de traducción de programas]]
* [[Compilador]]
* [[Depurador]]
* [[Lenguaje interpretado]]
* [[Lenguaje compilado]]
* [[Lenguaje compilado]]
* [[Interpretador de línea de comandos]] (Una forma de interpretador técnicamente relacionada pero mucho más simple)
* [[Guion (Informática)|Guion]]
* [[Intérprete de comandos]]
* [[Interpretador metacircular]]
* [[Compilación dinámica]] incluyendo la sección sobre la compilación incremental.
* [[Evaluación parcial]]

== Enlaces externos ==


*[http://drpubagump.ouaibou.info DrPubaGump] A tiny Interpreter written in Scheme, which provides to interpret PUBA-GUMP (a subset of BASIC) in Scheme
*[http://www.columbia.edu/acis/history/interpreter.html IBM Card Interpreters] page at Columbia University


[[Categoría:Lenguajes interpretados|Interpretado]]
[[Categoría:Herramientas de programación]]
[[Categoría:Programas de código objeto]]


[[ar:لغة مفسرة]]
[[ar:مفسر (برمجة)]]
[[bs:Interpreter]]
[[ca:Llenguatge interpretat]]
[[cs:Interpret (software)]]
[[de:Interpretersprache]]
[[da:Fortolker]]
[[en:Interpreted language]]
[[de:Interpreter]]
[[fr:Langage interprété]]
[[el:Διερμηνέας (υπολογιστές)]]
[[pl:Język interpretowany]]
[[en:Interpreter (computing)]]
[[pt:Linguagem interpretada]]
[[et:Interpretaator]]
[[ru:Интерпретируемый язык программирования]]
[[eu:Interpretatzaile]]
[[sv:Interpreterande programspråk]]
[[fa:مفسر (رایانه)]]
[[tr:Yorumlanan programlama dili]]
[[fi:Ohjelmointikielen tulkki]]
[[fr:Interprète (informatique)]]
[[he:מפרש (תוכנה)]]
[[hr:Interpreter]]
[[hu:Értelmező]]
[[is:Túlkur (tölvunarfræði)]]
[[it:Interprete (informatica)]]
[[ja:インタプリタ]]
[[ko:인터프리터]]
[[lt:Interpretatorius]]
[[ms:Pentafsir (pengkomputan)]]
[[nl:Interpreter]]
[[pl:Interpreter (program komputerowy)]]
[[pt:Interpretador]]
[[ro:Interpretor]]
[[ru:Интерпретатор]]
[[simple:Interpreter (computing)]]
[[sk:Interpreter (programovanie)]]
[[sl:Interpreter]]
[[sr:Интерпретатор]]
[[sv:Interpretator]]
[[th:โปรแกรมแปลคำสั่ง]]
[[tr:Yorumlayıcı]]
[[uk:Інтерпретатор]]
[[vi:Trình thông dịch]]
[[zh:直譯器]]

Revisión del 19:36 10 feb 2010

En ciencias de la computación, intérprete o interpretador es una cutusa programa informático capaz de analizar y ejecutar otros programas, escritos en un lenguaje de alto nivel. Los intérpretes se diferencian de los compiladores en que mientras estos traducen un programa desde su descripción en un lenguaje de programación al código de máquina del sistema, los primeros (los intérpretes) sólo realizan la traducción a medida que sea necesaria, típicamente, instrucción por instrucción, y normalmente no guardan el resultado de dicha traducción.

Usando un intérprete, un solo archivo fuente puede producir resultados iguales incluso en sistemas sumamente diferentes (ej. una PC y un PlayStation 3). Usando un compilador, un solo archivo fuente puede producir resultados iguales solo si es compilado a distintos ejecutables específicos a cada sistema.

Los programas interpretados suelen ser más lentos que los compilados debido a la necesidad de traducir el programa mientras se ejecuta, pero a cambio son más flexibles como entornos de programación y depuración (lo que se traduce, por ejemplo, en una mayor facilidad para reemplazar partes enteras del programa o añadir módulos completamente nuevos), y permiten ofrecer al programa interpretado un entorno no dependiente de la máquina donde se ejecuta el intérprete, sino del propio intérprete (lo que se conoce comúnmente como máquina virtual).

Para mejorar el desempeño, algunas implementaciones de programación de lenguajes de programación pueden interpretar o compilar el código fuente original en una más compacta forma intermedia y después traducir eso al código de máquina (ej. Perl, Python, MATLAB, y Ruby). Algunos aceptan los archivos fuente guardados en esta representación intermedia (ej. Python, UCSD Pascal y Java).

Comparando su actuación con la de un ser humano, un compilador equivale a un traductor profesional que, a partir de un texto, prepara otro independiente traducido a otra lengua, mientras que un intérprete corresponde al intérprete humano, que traduce de viva voz las palabras que oye, sin dejar constancia por escrito.

En la actualidad, uno de los entornos más comunes de uso de los intérpretes informáticos es Internet, debido a la posibilidad que estos tienen de ejecutarse independientemente de la plataforma.

Interpretadores de bytecode

Hay un espectro de posibilidades entre la interpretación y la compilación, dependiendo de la cantidad de análisis realizados antes de que el programa sea ejecutado. Por ejemplo, el Emacs Lisp es compilado a bytecode, que es una representación altamente comprimida y optimizada del código fuente del Lisp, pero no es código de máquina (y por lo tanto no está atado a cualquier hardware particular). Este código "compilado" es entonces interpretado por un interpretador de bytecode (que está escrito en C). En este caso, el código compilado es el código de máquina para una máquina virtual, que no está implementada en el hardware, sino en el interpretador de bytecode. El mismo acercamiento es utilizado con el código Forth usado en sistemas Open Firmware: el lenguaje fuente es compilado en "código F" (un bytecode), que entonces es interpretado por una máquina virtual.

Eficiencia

La desventaja principal de los interpretadores es que cuando se interpreta un programa, típicamente corre más lentamente que si hubiera sido compilado. La diferencia en velocidades puede ser minúscula o grande; a menudo un orden de magnitud y a veces más. Generalmente toma más tiempo correr un programa bajo un interpretador que correr el código compilado, pero puede tomar menos tiempo para interpretarlo que el tiempo total requerido para compilarlo y ejecutarlo. Esto es especialmente importante si se está haciendo y probando un código prototipo cuando un ciclo de editar, interpretar y depurar del interpretador, a menudo puede ser mucho más corto que el ciclo de editar, compilar, ejecutar y depurar del compilador.

La interpretación de código es más lenta que la ejecución de código compilado porque el interpretador debe analizar cada sentencia en el programa cada vez que es ejecutada y entonces realizar la acción deseada, mientras que el código compilado solo realiza la acción dentro de un determinado contexto fijo por la compilación. Este análisis en tiempo de ejecución se conoce como "sobrecarga interpretativa". En un interpretador, el acceso a las variables es también más lento porque el mapeo de identificadores hacia las localizaciones de almacenamiento debe hacerse repetidamente en tiempo de ejecución en vez de en el tiempo de compilación. Hay varios compromisos entre la velocidad de desarrollo al usar un interpretador y la velocidad de ejecución al usar un compilador. Algunos sistemas (ej., algunos LISPs) permiten al código interpretado y al compilado llamarse el uno al otro y compartir variables. Esto significa que una vez que una rutina ha sido probada y depurada bajo el interpretador puede ser compilada y por lo tanto beneficiarse de una ejecución más rápida mientras que otras rutinas están siendo desarrolladas. Muchos interpretadores no ejecutan el código fuente tal y como está sino que lo convierten en una forma interna más compacta. Por ejemplo, algunos interpretadores BASIC reemplazan palabras clave (keywords) con tokens de un simple byte que pueden ser usados para encontrar la instrucción en una tabla de saltos. Un interpretador puede bien usar el mismo analizador lexicográfico y el analizador sintáctico (parser) que el compilador y entonces interpretar el árbol de sintaxis abstracta resultante.

Interpretadores de árbol de sintáxis abstracta

En el espectro entre la interpretación y la compilación, otro acercamiento está transformando el código fuente en un árbol de sintaxis abstracta optimizado (AST), y después procediendo a ejecutar el programa siguiendo esta estructura arborescente.[1]​ En este acercamiento cada sentencia necesita ser analizada (parsed) solo una vez. Como una ventaja sobre el bytecode, el AST mantiene la estructura y las relaciones globales del programa entre las sentencias (que se pierden en una representación de bytecode), y proporciona una representación más compacta.[2]

Así, el AST se ha propuesto como un mejor formato intermedio para los compiladores justo a tiempo que el bytecode. También, permite realizar un mejor análisis durante tiempo de ejecución. Un interpretador Java basado en AST ha demostrado ser más rápido que un interpretador similar basado en bytecode,[3]​ gracias a las más poderosas optimizaciones permitidas al tener la estructura completa del programa, así como tipos de datos de alto nivel, disponibles durante la ejecución.

Compilación justo a tiempo

Para desdibujar más la distinción entre los interpretadores, los interpretadores de bytecode y la compilación, está la compilación justo a tiempo (o JIT), una técnica en la cual la representación intermedia es compilada a código de máquina nativo en tiempo de ejecución. Esto confiere la eficiencia de ejecutar el código nativo, al costo de tiempo de inicio y de un uso creciente de la memoria cuando el bytecode o el AST es compilado por primera vez. La optimización adaptativa es una técnica complementaria en la cual el interpretador hace un análisis de desempeño del programa que está corriendo (profiling) y compila sus partes más frecuentemente ejecutadas a código nativo. Ambas técnicas tienen algunas décadas, apareciendo en lenguajes tales como Smalltalk en los años 1980.

En años recientes, la compilación justo a tiempo ha ganado la atención de la mayoría de los implementadores de lenguajes de programación, con Java, Python, y el Microsoft .NET Framework todos ahora incluyendo JITs.

Interpretador de tarjeta perforada

El término "interpretador" frecuentemente se refería a una pieza de equipo de registro de unidad que podía leer tarjetas perforadas e imprimir los caracteres en la tarjeta en una forma que podía ser leída por humanos. El interpretador Numérico del IBM 550 y el Interpretador Alfabético del IBM 557 son ejemplos típicos a partir de 1930 y 1954, respectivamente.

Ejemplos

Algunos ejemplos de lenguajes que son normalmente interpretados en vez de compilados son:

Notas y referencias

  1. AST intermediate representations, Lambda the Ultimate forum
  2. A Tree-Based Alternative to Java Byte-Codes, Thomas Kistler, Michael Franz
  3. Trees Versus Bytes, BComp Honours thesis by Kade Hansson

Véase también

Enlaces externos

  • DrPubaGump A tiny Interpreter written in Scheme, which provides to interpret PUBA-GUMP (a subset of BASIC) in Scheme
  • IBM Card Interpreters page at Columbia University