Intérpretes y Diseño de Lenguajes de Programación

Transcripción

1 Intérpretes y Diseño de Lenguajes de Programación Jose Emilio Labra Gayo Juan Manuel Cueva Lovelle Raúl Izquierdo Castanedo Aquilino Adolfo Juan Fuente Mª Cándida Luengo Díez Francisco Ortín Soler Fecha: Abril

2 Tabla de Contenidos 1. Intérpretes Definición Estructura de un intérprete Ventajas de la utilización de intérpretes Aplicaciones de los sistemas basados en intérpretes Tipos de intérpretes Ejemplo de intérprete de código intermedio Ejemplo de intérprete de lenguaje recursivo Diseño de Lenguajes de Programación Aspectos lingüísticos Principios de diseño Técnicas de Especificación semántica Familias de Lenguajes Lenguajes de Dominio Específico Máquinas abstractas 39 Ejercicios Propuestos 41 Referencias

3 Definición 1. Intérpretes 1.1. Definición Un intérprete es un programa que analiza y ejecuta simultáneamente un programa escrito en un lenguaje fuente. En la Figura 1 se presenta el esquema general de un intérprete visto como una caja negra. Cualquier intérprete tiene dos entradas: un programa P escrito en un lenguaje fuente LF (en lo sucesivo, se denotará P/LF) junto con los datos de entrada; a partir de dichas entradas, mediante un proceso de interpretación va produciendo unos resultados. P/LF Intérprete de LF Datos Resultados Figura 1: Esquema general de un intérprete Los compiladores, a diferencia de los intérpretes, transforman el programa a un programa equivalente en un código objeto (fase de compilación), y en un segundo paso generan los resultados a partir de los datos de entrada (fase de ejecución). P/LF Compilador de LF Compilación Datos P/OBJ Resultados Ejecución 1.2. Estructura de un intérprete Figura 2: Esquema general de un compilador A la hora de construir un intérprete es conveniente utilizar una Representación Interna (RI) del lenguaje fuente a analizar. De esta forma, la organización interna de la mayoría de los intérpretes se descompone en los módulos: Traductor a Representación Interna: Toma como entrada el código del programa P en Lenguaje Fuente, lo analiza y lo transforma a la representación interna correspondiente a dicho programa P. Representación Interna (P/RI): La representación interna debe ser consistente con el programa original. Entre los tipos de representación interna, los árboles sintácticos son los más utilizados y, si las características del lenguaje lo permiten, pueden utilizarse estructuras de pila para una mayor eficiencia. Tabla de símbolos: Durante el proceso de traducción, es conveniente ir creando una tabla con información relativa a los símbolos que aparecen. La información a almacenar en dicha tabla de símbolos depende de la complejidad del lenguaje fuente. Se pueden almacenar etiquetas para instrucciones de salto, información sobre identificadores (nombre, tipo, línea en la que aparecen, etc.) o cualquier otro tipo de información que se necesite en la etapa de evaluación. Evaluador de Representación Interna: A partir de la Representación Interna anterior y de los datos de entrada, se llevan a cabo las acciones indicadas para obtener los resultados. Durante el proceso de evaluación es necesario contemplar la aparición de errores

4 Estructura de un intérprete Tratamiento de errores: Durante el proceso de evaluación pueden aparecer diversos errores como desbordamiento de la pila, divisiones por cero, etc. que el intérprete debe contemplar. Intérprete de LF P/LF Traductor LF a RI P/RI Tabla Símbolos Datos Evaluador RI Tratamiento de Errores Resultados Errores Figura 3: Organización interna de un intérprete Dependiendo de la complejidad del código a analizar, el intérprete puede contener módulos similares a los de un compilador tradicional: Análisis léxico, Sintáctico y Semántico. Durante la evaluación, el intérprete interactúa con los recursos del sistema como la memoria, discos, etc. Muchos sistemas interpretados liberan al programador del manejo explícito de memoria mediante técnicas de recolección de basura. A la hora de evaluar la representación interna, existen dos métodos fundamentales: la interpretación iterativa y la interpretación recursiva Interpretación Iterativa La interpretación iterativa es apropiada para lenguajes sencillos, donde se analiza y ejecuta cada expresión de forma directa, como podrían ser los códigos de máquinas abstractas o lenguajes de sentencias simples. La interpretación consiste en un ciclo básico de búsqueda, análisis y ejecución de instrucciones. El esquema sería: Inicializar REPETIR Buscar siguiente Instrucción i SI encontrada ENTONCES Analizar i Ejecutar i HASTA (que no haya más instrucciones) Figura 4: Interpretación iterativa Cada instrucción se busca en el almacenamiento (memoria o disco) o, en algunos casos, es introducida directamente por el usuario. Luego la instrucción es analizada en sus componentes y ejecutada. Normalmente, el lenguaje fuente contiene varios tipos de instrucciones, de forma que la ejecución se descompone en varios casos, uno por cada tipo de instrucción. En la página 42, se construye un intérprete iterativo de un sencillo lenguaje intermedio Interpretación Recursiva Comúnmente, el diseño de nuevos lenguajes de programación se realiza en dos fases: Una primera fase de especificación semántica mediante la construcción de un intérprete prototipo que actúa como una especificación ejecutable y una segunda fase de implementación del compilador de dicho lenguaje. Para la construcción de prototipos suele utilizarse un modelo de interpretación recursiva donde las sentencias pueden estar compuestas de otras sentencias y la ejecución de una sentencia puede lanzar la ejecución de otras sentencias de forma recursiva. Los intérpretes recursivos no son apropiados para aplicaciones prácticas debido a su ineficiencia y se utilizan únicamente como prototipo ejecutable del lenguaje. El problema de especificar un lenguaje mediante un intérprete prototipo es decidir en qué lenguaje se implementa dicho intérprete. Dicho lenguaje debe ser suficientemente expresivo y no ambigüo para definir claramente cómo funcionan las diferentes construcciones. En muchos casos se opta por utilizar lenguajes ya implementados pero que carecen de una especificación semántica clara. La tendencia actual es investigar técnicas de especificación semántica formal que permitan generar automáticamente este tipo de intérpretes [Espinosa94], [Liang96], [Steele94]

5 Ventajas de la utilización de intérpretes 1.3. Ventajas de la utilización de intérpretes En general, la utilización de compiladores permite construir programas más eficientes que los correspondientes interpretados. Esto es debido a que durante la ejecución de código compilado no es necesario realizar complejos análisis (ya se hicieron en tiempo de compilación), además, un buen compilador es capaz de detectar errores y optimizar el código generado. Los intérpretes, por definición, realizan la fase de análisis y ejecución a la vez, lo cual imposibilita tales optimizaciones. Por esta razón, los sistemas interpretados suelen ser menos eficientes que los compilados. No obstante, los nuevos avances informáticos aumentan la velocidad de procesamiento y capacidad de memoria de los ordenadores. Actualmente, la eficiencia es un problema menos grave y muchas veces se prefieren sistemas que permitan un desarrollo rápido de aplicaciones que cumplan fielmente la tarea encomendada. A continuación se enumeran una serie de ventajas de los sistemas interpretados: Los intérpretes, en general, son más sencillos de implementar. Lo cual facilita el estudio de la corrección del intérprete y proporciona nuevas líneas de investigación como la generación automática de intérpretes a partir de las especificaciones semánticas del lenguaje. Proporcionan una mayor flexibilidad que permite modificar y ampliar características del lenguaje fuente. Muchos lenguajes como Lisp, APL, Prolog, etc. surgieron en primer lugar como sistemas interpretados y posteriormente surgieron compiladores. No es necesario contener en memoria todo el código fuente. Esto permite su utilización en sistemas de poca memoria o en entornos de red, en los que se puede obtener el código fuente a medida que se necesita [Plezbert 97]. Facilitan la meta-programación. Un programa puede manipular su propio código fuente a medida que se ejecuta. Esto facilita la implementación de sistemas de aprendizaje automatizado y reflectividad [Aït Kaci 91]. Aumentan la portabilidad del lenguaje: Para que el lenguaje interpretado funcione en otra máquina sólo es necesario que su intérprete funcione en dicha máquina. Puesto que no existen etapas intermedias de compilación, los sistemas interpretados facilitan el desarrollo rápido de prototipos, potencian la utilización de sistemas interactivos y facilitan las tareas de depuración Aplicaciones de los sistemas basados en intérpretes Los sistemas interpretados han tenido una gran importancia desde la aparición de los primeros ordenadores. En la actualidad, la evolución del hardware abre nuevas posibilidades a los sistemas interpretados. La preocupación ya no es tanto la eficiencia como la capacidad de desarrollo rápido de nuevas aplicaciones. Las principales aplicaciones podrían resumirse en: Intérpretes de Comandos: Los sistemas operativos cuentan con intérpretes de comandos como el Korn-Shell, C-Shell, JCL, etc. Estos intérpretes toman un lenguaje fuente que puede incluir sentencias de control (bucles, condiciones, asignaciones, etc.) y ejecutan los diferentes comandos a medida que aparecen en el lenguaje. Lenguajes basados en Escritos (Scripting Languages), diseñados como herramientas que sirvan de enlace entre diferentes sistemas o aplicaciones. Suelen ser interpretados con el fin de admitir una mayor flexibilidad a la hora de afrontar las peculiaridades de cada sistema. Podrían destacarse Perl, Tcl/Tk, JavaScript, WordBasic [Ousterhout 97] Entornos de Programación: Existen ciertos lenguajes que contienen características que impiden su compilación o cuya compilación no es efectiva. Estos lenguajes suelen disponer de un complejo entorno de desarrollo interactivo con facilidades para la depuración de programas. Entre estos sistemas pueden destacarse los entornos de desarrollo para Lisp, Visual Basic, Smalltalk, etc. Lenguajes de Propósito Específico: Ciertos lenguajes incluyen sentencias que realizan tareas complejas en contextos específicos. Existe una gran variedad de aplicaciones en las que se utilizan este tipo de lenguajes como consultas de Bases de Datos, simulación, descripción de hardware, robótica, CAD/CAM, música, etc. Sistemas en Tiempo Real: Entornos que permiten modificar el código de una aplicación en tiempo de ejecución de forma interactiva. Intérprete de Código Intermedio: Una tendencia tradicional en el diseño de compiladores es la generación de un código intermedio para una máquina abstracta, por ejemplo, el P-Code de Pascal o los bytecodes de Java. El siguiente paso puede ser: generación del código objeto a partir del código intermedio para una máquina concreta, finalizando el proceso de compilación o interpretar dicho código intermedio en una máquina concreta. La tendencia habitual es definir un lenguaje intermedio independiente de una máquina concreta. Para ello, suele definirse una máquina virtual que contenga las instrucciones definidas por el lenguaje intermedio, permitiendo una mayor portabilidad. Un ejemplo sería la Máquina Virtual de Java, que es simulada en la mayoría de los visualizadores Web

6 Tipos de intérpretes Datos P/LF Compilador LF a CI P/CI Intérprete de CI Resultados Figura 5: Esquema de Compilador con Intérprete de código intermedio En la siguiente tabla, tomada de [Hudak, 98] se resumen algunos de los principales lenguajes de propósito específico con sus respectivas aplicaciones. Lenguaje Perl VHDL Tex, Latex, troff HTML, SGML, XML Lex, Yacc SQL, LDL, QUEL pic, PostScript Open GL Tcl, Tk Mathematica, Maple Autolisp/AutoCAD Csh, Ksh IDL Emacs Lisp Visual Basic Aplicación Manipulación de textos y ficheros. scripting Descripción de Hardware Formateo de documentos Estructuración de documentos Análisis léxico y sintáctico Bases de datos Gráficos en 2 dimensiones Gráficos en 3 dimensiones de alto nivel Interfaces gráficos de usuario Computación simbólica matemática Diseño asistido por ordenador Intérpretes de Comandos Tecnología de componentes Edición de texto scripting 1.5. Tipos de intérpretes A continuación se va a realizar una clasificación de los diferentes métodos de interpretación según la estructura interna del intérprete. Es conveniente observar que algunos métodos podrían considerarse híbridos, ya que mezclan los procesos de compilación e interpretación Intérpretes puros Los intérpretes puros son los que analizan y ejecutan sentencia a sentencia todo el programa fuente. Siguen el modelo de interpretación iterativa y, por tanto, se utilizan principalmente para lenguajes sencillos. Los intérpretes puros se han venido utilizando desde la primera generación de ordenadores al permitir la ejecución de largos programas en ordenadores de memoria reducida, ya que sólo debían contener en memoria el intérprete y la sentencia a analizar y ejecutar en cada momento. El principal problema de este tipo de intérpretes es que si a mitad del programa fuente se producen errores, se debe de volver a comenzar el proceso

7 Tipos de intérpretes Intérprete de LF P/LF Traductor LF a RI Instrucción en curso P/RI Nº Instrucción Tabla Símbolos Datos Evaluador RI Tratamiento de Errores Resultados Errores Figura 6: Esquema de un intérprete puro En la figura se representa el esquema general de un intérprete puro. Se puede observar que el lenguaje fuente se traduce a una representación interna (texto o binaria) que puede ser almacenada en memoria o en disco. Esta representación interna tiene todas las instrucciones numeradas o colocadas consecutivamente en estructuras de tamaño fijo (por ejemplo un array o posiciones consecutivas de memoria, o un fichero binario de estructuras de tamaño fijo). Mientras se realiza este paso se puede construir la tabla de símbolos o etiquetas, que es una tabla que contiene una estructura donde están todas las etiquetas y su posición en el programa fuente (las etiquetas se utilizan tanto en las instrucciones de salto como en las llamadas a procedimientos y funciones). Una vez que este proceso ha finalizado, comienza la ejecución por la primera instrucción del código, que se envía al evaluador de instrucciones, éste la ejecuta (recibiendo datos si es necesario o enviando un mensaje de error). El evaluador de instrucciones también determina la instrucción siguiente a ejecutar, en algunos casos previa consulta a la tabla de etiquetas. En caso de que no haya saltos (GOTO) se ejecuta la siguiente instrucción a la instrucción en curso Intérpretes avanzados Los intérpretes avanzados o normales incorporan un paso previo de análisis de todo el programa fuente. Generando posteriormente un lenguaje intermedio que es ejecutado por ellos mismos. De esta forma en caso de errores sintácticos no pasan de la fase de análisis. Se utilizan para lenguajes más avanzados que los intérpretes puros, ya que permiten realizar un análisis más detallado del programa fuente (comprobación de tipos, optimización de instrucciones, etc.) Intérpretes incrementales Existen ciertos lenguajes que, por sus características, no se pueden compilar directamente. La razón es que pueden manejar objetos o funciones que no son conocidos en tiempo de compilación, ya que se crean dinámicamente en tiempo en ejecución. Entre estos lenguajes, pueden considerarse Smalltalk, Lisp o Prolog. Con el propósito de obtener una mayor eficiencia que en la interpretación simple, se diseñan compiladores incrementales. La idea es compilar aquellas partes estáticas del programa en lenguaje fuente, marcando como dinámicas las que no puedan compilarse. Posteriormente, en tiempo de ejecución, el sistema podrá compilar algunas partes dinámicas o recompilar partes dinámicas que hayan sido modificadas. Estos sistemas no producen un código objeto independiente, sino que acompañan el sistema que permite compilar módulos en tiempo de ejecución (run time system) al código objeto generado. Normalmente, los compiladores incrementales se utilizan en sistemas interactivos donde conviven módulos compilados con módulos modificables [Rober94] Evaluadores Parciales La utilización de evaluadores parciales o especializadores surge al considerar que muchos programas contienen dos tipos de datos de entrada. Existen una serie de datos de entrada que son diferentes en cada ejecución mientras que otros datos no varían de una ejecución a otra. El primer conjunto, se conoce como datos de entrada dinámicos (se denotará como Din), mientras que el segundo conjunto, serían los datos de entrada estáticos (Est). Dado un programa P, el proceso de evaluación parcial consiste en construir otro programa especializado P Est para los datos estáticos de P. El programa P Est suele estar escrito en el mismo lenguaje fuente que P y se debe garantizar que cuando se le - 7 -

8 Tipos de intérpretes presenten los datos dinámicos produzca los mismos resultados que si se hubiesen presentado todos los datos al programa P original. P/LF Evaluador Parcial Est Din Datos P Est /LF Compilador LF a OBJ P Est /OBJ Resultados Figura 7: Evaluación Parcial Ejemplo: Considérese el siguiente fragmento de programa P1 que toma la entrada de dos ficheros diferentes, fichest y fichdin y escribe el resultado en la salida estándar. read(fichest,a); while (a > 0) do begin read(fichdin,b); if (a > 10) then write (b - 2 * a) else write (a * a + b); read(fichest,a); end Figura 8: Programa P1 Si el contenido de fichest fuese siempre el evaluador parcial podría generar un programa especializado para dicho conjunto de datos, obteniendo P1 Est: read(fichdin,b); write(25 + b); read(fichdin,b); write(b - 24); read(fichdin,b); write(49 + b); Figura 9: Programa P1 Est La principal ventaja de la evaluación parcial es la eficiencia. Si se conoce de antemano que un programa P va a ejecutarse muchas veces con un mismo conjunto de datos Est pero diferentes datos Din, será más eficiente evaluar parcialmente P para obtener P Est y ejecutar luego P est. En el ejemplo, puede observarse que es posible eliminar el bucle while y la sentencia if debido a que las condiciones dependen de datos estáticos. Sin embargo, las cosas no son siempre tan fáciles, considérese que en el programa P1 se elimina la última sentencia read(fichest,a) del bucle. Entonces el evaluador parcial, podría entrar en un bucle infinito intentando generar el programa especializado. Por este motivo, los evaluadores parciales deben realizar un complejo análisis del programa fuente para detectar que el proceso no genere un bucle infinito. El análisis de tiempo de enlace (bindingtime analysis) es una técnica que se encarga de detectar qué valores son estáticos y pueden evaluarse y cuáles no. Una aplicación interesante de la evaluación parcial es la posibilidad de generar compiladores a partir de intérpretes. Para ello, supóngase que a la entrada del evaluador parcial se presenta el intérprete de un lenguaje de programación LF escrito en un lenguaje de transición LT, junto con un programa P escrito en en LF. El evaluador parcial generará un intérprete especializado para el programa P en el lenguaje LT. Suponiendo la existencia de un compilador para el lenguaje LT, se puede obtener el intérprete especializado en código objeto que, una vez presentados los datos de entrada D genere los resultados

9 Tipos de intérpretes Int de LF/LT Evaluador Parcial Actúa como un compilador de LF a Obj P/LF D Datos Int de LF P/LF /LT Compilador de LT a OBJ Int de LF P/LF /OBJ Resultados Figura 10: Obtención de un compilador a partir de un intérprete mediante evaluación parcial Dado que los intérpretes se utilizan como especificaciones semánticas de un lenguaje. La obtención automatizada de un compilador a partir de la definición del intérprete permite alcanzar la eficiencia de un compilador sin perder la corrección semántica de un intérprete. La evaluación parcial tiene otras aplicaciones interesantes en campos como el ray-tracing [Ander94], modelización de mundos virtuales [Besh97], reconocimiento de patrones, consultas a bases de datos, redes neuronales, etc. Para una revisión general de la evaluación parcial puede consultarse [Jones 93] [Jones 96] y [Pagan 91] Compiladores Just in Time Con la aparición de Internet surge la necesidad de distribuir programas de una forma independiente de la máquina permitiendo su ejecución en una amplia variedad de plataformas. Los códigos de bytes de la máquina Virtual de Java permiten la ejecución de programas distribuidos, ya que la mayoría de los visualizadores tienen un mecanismo capaz de interpretarlos. La interpretación de códigos de bytes supone una demora en los tiempos de ejecución. Para evitar la interpretación, muchos sistemas transforman los códigos de bytes en código nativo siguiendo el modelo just in time. En este modelo, una unidad de compilación o clase se transmite en el formato de códigos de bytes, pero no se realiza la interpretación. En lugar de ello, el código es compilado a código nativo justo en el momento en que lo necesita el programa que se está ejecutando. A/(Código nativo) B/(Código Fuente) Call B Compilador Ejecución B/(Código nativo) Figura 11: Compilación de una clase Just in Time - 9 -

10 Tipos de intérpretes En la figura se muestra el ejemplo de una unidad de compilación A compilada (en código nativo) que encuentra una instrucción de llamada a otra unidad B en código fuente (códigos de byte 1 ). El sistema realiza dos acciones: Compila la unidad B a código nativo. Continúa la ejecución con el código nativo compilado de la unidad B Las principales ventajas de la compilación Just in Time son: 1.- Los programas grandes contienen porciones de código que no son ejecutadas en una ejecución típica del programa. Por ejemplo, un visualizador de páginas Web, podría contener rutinas para manejar diversos formatos de los datos transmitidos, pero algunos de dichos formatos podrían no ser utilizados en una determinada ejecución del visualizador. Puesto que la compilación Just in Time sólo traduce aquéllas porciones de código que se necesitan, se evita el tener que compilar código que no se va a utilizar. 2.- Los sistemas tradicionales realizan la compilación de todo el código antes de la ejecución, lo que para el usuario puede presentar un lapso de tiempo substancial entre el momento en que todas las unidades de compilación han sido transmitidas y el momento en que la ejecución puede comenzar. Esta técnica tiende a repartir el tiempo de compilación a lo largo de la ejecución del programa. El efecto producido al interrumpir la ejecución para compilar una unidad es similar al producido por la recolección de basura Compilación Continua La compilación continua surge como un intento de mejorar la compilación Just in Time. El sistema mezcla el proceso de compilación a código nativo con el proceso de interpretación. Para conseguirlo, el sistema dispone de dos módulos: un módulo de intérpretación de los códigos de bytes y otro módulo de compilación de códigos de bytes a código nativo. La idea consiste en que ambos módulos actúen a la vez (lo ideal sería disponer de dos procesadores), de forma que el sistema no se detenga a compilar un módulo, sino que vaya interpretándolo hasta que el compilador haya generado el código nativo. En la figura se distinguen los módulos que intervienen: Código: El código contiene una mezcla de código fuente y código nativo del programa. Inicialmente todo el código está sin compilar, pero a medida que el programa es ejecutado, el compilador genera traducciones a código nativo de las unidades de compilación. Compilador: El módulo compilador traduce las unidades de compilación a código nativo. A medida que se finaliza la traducción de una unidad, la versión en código nativa se deja disponible al intérprete. Intérprete: El módulo intérprete se responsabiliza de la ejecución actual del programa. Comienza interpretando el código fuente, haciendo saltos a las versiones en código nativo a medida que éstas están disponibles. Monitor: Se encarga de coordinar la comunicación entre los dos módulos anteriores. Intérprete Código Compilador Monitor Figura 12: Compilación Continua La principal ventaja de la compilación continua respecto a la compilación Just in Time radica en no tener que esperar a compilar una unidad para comenzar su ejecución. En [Plezbert 96], [Plezbert 97] se estudian diferentes estrategias y se presenta con más detalle este modelo de compilación. A modo de repaso de las estrategias tradicional, Just in time y continua, considérese el siguiente problema: 1 Obsérvese que la unidad B, podría no estar cargada en la máquina, siendo necesario acceder a ella a través de la red para obtener sus códigos de byte

11 Tipos de intérpretes Desde una máquina cliente, desea ejecutarse un programa P cargado en un servidor. El programa consta de 3 módulos 'A', 'B' y 'C' en códigos de bytes. El tiempo de transmisión de cada módulo desde el servidor al cliente es de 2sg. El tiempo de compilación de códigos de bytes a código nativo es de 0.2sg por módulo y el tiempo de ejecución interpretando códigos de bytes es el doble del tiempo de ejecución en código nativo. Estudiar una ejecución particular que comienza por el módulo A, llama al módulo C y, tras ejecutar el módulo C, finaliza. Si dicha ejecución se realiza en código nativo, el módulo A tarda 1.4sg. mientras que el módulo C tarda 1sg. Los tiempos de transmisión de órdenes entre el servidor y el cliente se consideran despreciables. Se trazará un diagrama de secuencias a fin de mostrar las diferencias entre cada estrategia. Compilación Tradicional Compilación Just-in-Time Compilación Continua Cliente Cliente Cliente Ejecución Compilador Servidor Ejecución Compilador Servidor Ejecución Intérprete Compilador Servidor 0 A? 0 A? 0 A? A/LF A/LF A/LF 2 2 2,2 2 B/LF 3,6 A/OBJ C? A/LF C/LF 4 4 C/LF C/LF 4,8 C/OBJ C? 6 6,6 5,6 5,8 6,8 C/OBJ 5,8 A/OBJ 8 C/OBJ 9 Figura 13: Diagrama de Secuencias comparando técnicas de compilación En el esquema tradicional, el sistema solicita el módulo A al servidor y éste envía todos los módulos del programa (A, B y C). Puesto que cada módulo tarda 2sg en transmitirse, la transmisión finaliza a los 6 sg, momento en el que se compilan los tres módulos (tardando 0,2 sg por módulo). Al finalizar la compilación de los tres módulos, comienza la ejecución por el módulo A. Por tanto, el tiempo de retardo, desde que el usuario solicita el módulo hasta que éste comienza a ejecutarse es de 6,6sg. Tras ejecutarse el módulo A, se ejecuta el módulo C y el tiempo total de ejecución del programa serían 9 sg. En el esquema Just-in-time el servidor envía solamente el módulo A (2 sg), el cual es compilado en 0,2sg. El tiempo de retardo será 2,2 sg. Al finalizar la ejecución de A, se solicita el módulo C al servidor, tras recibirlo y compilarlo, comienza su ejecución y el tiempo total de ejecución serán 6,8 sg. Finalmente, en el esquema de compilación continua, tras solicitar y recibir el módulo A, el cliente comienza la ejecución interpretando códigos de bytes. El tiempo de retardo para el usuario serán 2 sg. El tiempo de ejecución del módulo A será 2,8 sg, el doble de 1,4 sg, puesto que se interpretan códigos de bytes. Mientras se realiza la interpretación, el cliente solicita otros módulos. En un caso óptimo, el cliente solicitaría el módulo C y éste se compilaría. Al finalizar la ejecución de A, podría continuarse con la ejecución de C. El tiempo de ejecución total sería 5,8 sg. Obsérvese que se ha considerado una situación óptima en la que el cliente solicite el módulo adecuado. El cliente podría haberse equivocado y solicitar el módulo B, comportándose peor este esquema

12 Ejemplo de intérprete de código intermedio 1.6. Ejemplo de intérprete de código intermedio Descripción del lenguaje En esta sección se describirá la implementación de un intérprete de un lenguaje intermedio básico. El lenguaje consta únicamente de un tipo int y se basa en una pila de ejecución sobre la que se realizan las principales instrucciones aritméticas. Las instrucciones del lenguaje son: INT v PUSHA v PUSHC c LOAD STORE ADD SUB MUL DIV LABEL e JMPZ e JMPGZ e GOTO e JMPLZ e OUTPUT v INPUT v ECHO cad Declara v como una variable de tipo entero Mete en la pila la dirección de la variable v Mete en la pila la constante c Saca de la pila un elemento y carga en la pila el contenido en memoria de dicho elemento Saca de la pila dos elementos y carga en la dirección del segundo elemento el contenido del primero Saca dos elementos de la pila, los suma y mete el resultado en la pila Saca dos elementos de la pila, los resta y mete el resultado en la pila Saca dos elementos de la pila, los multiplica y mete el resultado en la pila Saca dos elementos de la pila, los divide y mete el resultado en la pila Establece una etiqueta e Saca un elemento de la pila y, si es igual a cero, continúa la ejecución en la etiqueta e Saca un elemento de la pila y, si es mayor que cero, continúa la ejecución en la etiqueta e Continúa la ejecución en la etiqueta e Saca un elemento de la pila y, si es menor que cero, continúa la ejecución en la etiqueta e Muestra por pantalla el contenido de la variable v Lee un valor y lo inserta en la posición de memoria referenciada por v Muestra por pantalla la cadena cad Figura 14: Instrucciones del código intermedio Desde el punto de vista sintáctico un programa está formado por una secuencia de instrucciones. Las variables y etiquetas son identificadores formados por una secuencia de letras y dígitos que comienzan por letra y se permiten comentarios con el formato de C++ (/*...*/) y (//...). Ejemplo: El siguiente programa calcula el factorial de un número. INT var // Read v INPUT var INT i // int i = 1; PUSHA i PUSHC 1 STORE INT Res // int R = 1; PUSHA Res PUSHC 1 STORE LABEL test // while (i < v) PUSHA i LOAD PUSHA v LOAD SUB JMPLZ endloop PUSHA Res // R = R * i PUSHA Res LOAD PUSHA i LOAD MUL STORE PUSHA i // i++; PUSHA i LOAD PUSHC 1 ADD STORE GOTO test // endwhile LABEL endloop OUTPUT Res // write Res Implementación del Intérprete Representación del Código Intermedio El código intermedio se representará mediante una clase abstracta Code con una subclase por cada tipo de instrucción. class Code { public: virtual void exec(context &) = 0; virtual string id() const = 0; ;

13 Ejemplo de intérprete de código intermedio El método exec implementará la forma en que se ejecuta cada instrucción actuando sobre el contexto que se pasa como argumento. El método id() devuelve la cadena identificativa de cada código de instrucción. Las diferentes instrucciones son subclases de la clase Code: class PushA: public Code { public: virtual void exec(context &c); virtual string id() const { return PUSHA ; ;... private: string argument; ; class PushC: public Code { public: virtual void exec(context &c); virtual string id() const { return PUSHC ; ;... private: int constant; ; class Load: public Code { public: virtual void exec(context &c); virtual string id() const { return LOAD ; ;... ; class Add: public Code { public: virtual void exec(context &c); virtual string id() const { return ADD ; ;... ;... Code exec() PushA exec() argument PushC exec() constant Load exec() Add exec()... Figura 15: Representación de códigos de instrucción Un programa está formado por una secuencia de códigos de instrucción: Program exec() 1..n Code exec() Figura 16: Representación de Programas class Program: public ProgramNode { public: void addcode(code *); int getcount(); void setcount(int ); void exec(context &); private: int _count; // instruction counter vector<code*> _code; ;

14 Ejemplo de intérprete de código intermedio Contexto de Ejecución El contexto de ejecución se representa mediante un objeto Contexto que agrupa las estructuras necesarias para simular el funcionamiento de la máquina abstracta en tiempo de ejecución. En el lenguaje mostrado, los elementos del contexto son: Memoria (Memory): Simula la memoria de la máquina y se forma mediante una lista de valores indexada por direcciones. En el ejemplo, tanto los valores como las direcciones son enteros. Pila de Ejecución (ExecStack): Contiene la pila de ejecución donde se almacenan los valores. Sobre esta pila actúan directamente las instrucciones PUSHA, PUSHC, LOAD, STORE, etc. Tabla de Símbolos (SymTable): Contiene información sobre los identificadores declarados y las etiquetas Registros: El contexto de ejecución contiene una serie de registros o variables globales como el contador de instrucciones (icount), la dirección de memoria libre (StackP) o el argumento de la instrucción actual (arg) Context Registers - Count - StackP Memory assign getval SymbolTable ExecStack push pop Memoria Figura 17: Contexto de ejecución La memoria se simula mediante una clase Memory que contiene una lista de valores (enteros) indexada por direcciones (también enteros). typedef int TValue; typedef int TDir; const TValue defaultvalue = -1; class Memory { public: Memory(TDir size = 100); void assign(tdir, TValue); TValue getval(tdir); TDir getsize(); private: TDir _size; vector<tvalue> _store; void checkrange(tdir n); ; El constructor inicializa los contenidos de la memoria a los valores por defecto (se le pasa un argumento indicando el tamaño de memoria deseado). El método assign asocia una dirección de memoria con un valor. Internamente, la memoria se representa como un vector de valores. La memoria almacena las variables declaradas por el programa. A medida que se declara una nueva variable, se reserva espacio para ella en la memoria. Aunque el lenguaje considerado no contiene variables locales (una vez declarada una variable, persiste hasta el final de la ejecución), una posible ampliación podría requerir este tipo de variables (por ejemplo, si se consideran procedimientos recursivos). En ese caso, conviene manejar la memoria como una pila LIFO, de forma que las variables locales se almacenan en la pila al entrar en un bloque y se sacan de la pila al salir del bloque. Este esquema se conoce como memoria Stack. Para su simulación, se utiliza la variable StackP que indica la siguiente posición libre de memoria. Cuando se ejecuta una instrucción INT id se asigna al identificador id de la tabla de símbolos la dirección StackP y se incrementa StackP. Nota: En el lenguaje intermedio propuesto tampoco es necesario manejar memoria dinámica o Heap. Si se contemplasen instrucciones de creación dinámica de elementos, sería necesario reservar una zona de la memoria para estos elementos y gestionar dicha zona mediante técnicas convencionales. Dependiendo del lenguaje a implementar, la gestión de memoria dinámica podría incluir recolección de basura

15 Ejemplo de intérprete de código intermedio Pila de Ejecución La pila de ejecución se implementa mediante una clase execstack con las operaciones clásicas sobre pilas, push y pop. class ExecStack { public: void push (const TValue& ); TValue pop (); void clearstack(); private: vector <TValue> Stack; Internamente, la pila de ejecución se representa también como un vector de valores. Tabla de Símbolos La tabla de símbolos se utiliza en dos contextos diferentes: 1.- En la fase de análisis léxico/sintáctico: La tabla contiene información de las palabras reservadas con el fin de detectar las diversas construcciones del lenguaje. A su vez, en estas fases, se almacenan en la tabla las etiquetas (con las direcciones en que aparecen) en la tabla. 2.- En la fase de ejecución: Se almacenan en la tabla las variables declaradas con la diracción de memoria a la que referencian. A su vez, en las instrucciones de salto, se consulta la dirección de la etiqueta en la tabla. La tabla se implementa mediante una estructura Hash indexada por identificadores. Los nodos de la tabla son objetos de tres tipos: Palabras reservadas: Códigos de las diferentes instrucciones (PUSHC, LOAD, ADD, etc.). Estos códigos contienen una referencia al objeto de la clase Code que indica el código de instrucción correspondiente. Etiquetas: A medida que el analizador sintáctico encuentra etiquetas, inserta su posición en la tabla de símbolos. De esta forma, no es necesario realizar dos pasadas por el código fuente (una para buscar etiquetas y otra para ejecutar). Variables: Se almacena información de las variables declaradas y la dirección de memoria en que fueron declaradas Los tres tipos de nodos se representan mediante clases correspondientes con una superclase STNode común. SymbolTable addentry lookup addinstrcodes 1..n STNode (abstract) InstrNode LabelNode VarNode Code code int instr int dir Figura 18: Tabla de Símbolos typedef enum { SInstr, SLabel, SVar SymbolType; class STNode { public: virtual SymbolType type() = 0; ; class InstrNode: public STNode { public: InstrNode(Code *); Code* getcode() const; SymbolType type(); private: Code* _code; ; class LabelNode: public STNode { public: LabelNode(int i); int geti() const; SymbolType type(); private:

16 Ejemplo de intérprete de código intermedio int ; _instr; class VarNode: public STNode { public: VarNode(int); TDir getdir() const; SymbolType type(); private: TDir _dir; ; class SymbolTable { public: STNode* lookup (string); void addentry (string, STNode *); void addinstrcodes (); private: map<string, STNode*, less<string> > _table; ; Los métodos addentry y lookup insertan y buscan un valor en la tabla de símbolos. El método addinstrcodes() es llamado antes de realizar el análisis sintáctico para insertar los códigos de instrucción o palabras reservadas en la tabla de símbolos Ejecución de Instrucciones El programa (formado por una lista de instrucciones) consta de un método execute. El método inicializa el contador de instrucciones a cero y se mete en un bucle ejecutando la instrucción indicada por el contador e incrementando el contador. El bucle se realiza mientras el contador de instrucciones sea menos que el número de instrucciones del programa. void Program::exec(Context &context) { int i; // current instruction context.setcount(0); while ((i=context.getcount()) < _icount) { _code[i]->execute(context); context.incicount(); Cada código de instrucción redefine el método virtual execute según su propia semántica: void IntDecl::execute(Context &c) { c.newint(argument); void PushA::execute(Context &c) { c.push(c.lookup(argument)); void PushC::execute(Context &c) { c.push(constant); void Load::execute(Context &c) { TValue d = c.pop(); c.push(c.getval(d)); void Store::execute(Context &c) { TValue v = c.pop(); TValue d = c.pop(); c.setval(d,v); void Input::execute(Context &c) { TValue v; cout << "Value of " << argument << "?"; cin >> v; TDir d = c.lookup(argument); c.setval(d,v);

17 Ejemplo de intérprete de código intermedio void Output::execute(Context &c) { TDir d = c.lookup(argument); TValue v = c.getval(d); cout << argument << " = " << v << endl; void Add::execute(Context &c) { TValue v1 = c.pop(); TValue v2 = c.pop(); c.push(v1+v2); void Sub::execute(Context &c) { TValue v1 = c.pop(); TValue v2 = c.pop(); c.push(v1-v2); void Mul::execute(Context &c) { TValue v1 = c.pop(); TValue v2 = c.pop(); c.push(v1*v2); void Div::execute(Context &c) { TValue v1 = c.pop(); TValue v2 = c.pop(); if (v2 == 0) RunningError("division by 0"); c.push(v1/v2); void Label::execute(Context &c) { void JmpZ::execute(Context &c) { TValue v = c.pop(); if (v == 0) { int newi = c.getlabel(argument); c.seticount(newi-1); void JmpLZ::execute(Context &c) { TValue v = c.pop(); if (v < 0) { int newi = c.getlabel(argument); c.seticount(newi-1); void JmpGZ::execute(Context &c) { TValue v = c.pop(); if (v > 0) { int newi = c.getlabel(argument); c.seticount(newi-1); void Goto::execute(Context &c) { int newi = c.getlabel(argument); c.seticount(newi-1); void Echo::execute(Context &c) { cout << argument << endl; El control de errores se realiza mediante el mecanismo de manejo de excepciones de C++. Cuando se produce un error se lanza una excepción con información del tipo de error. El programa principal se encarga de capturar los diferentes tipos de excepciones e informar al usuario de los mensajes correspondientes

18 Ejemplo de intérprete de código intermedio Análisis léxico y sintáctico Como cualquier otro procesador, el intérprete requiere la implementación de un análisis léxico y sintáctico del código fuente para obtener el código intermedio que posteriormente será interpretado. Para ello, se debe especificar la gramática, que en este caso es muy sencilla: <Program> ::= { <Instr> <Instr> ::= <código> <arg> <código> ::= INT PUSHA PUSHC LOAD STORE INPUT OUTPUT ECHO ADD SUB MUL DIV LABEL GOTO JMPLZ JMPZ <arg> ::= <ident> <integer> <vacio> Figura 19: Gramática del Lenguaje Dada la sencillez de la gramática, el analizador léxico y sintáctico se han desarrollado directamente sin herramientas tipo Lex o Yacc. El analizador léxico se implementó mediante una clase Scanner: class Scanner { public: Scanner(istream *); Token* nexttoken(void); void tokenback();... private:... Token* _token; istream* _input; ; El constructor toma como argumento un flujo de entrada desde el cual se van a leer los caracteres. El método nexttoken analiza dicho flujo de entrada y devuelve el siguiente token. El método tokenback se utiliza para que la siguiente llamada a nextotoken devuelva el último token analizado. El analizador sintáctico es recursivo descendente y se ha representado mediante una clase abstracta Parser de la cual derivan las clases que analizan las diversas construcciones del lenguaje. Con el fin de separar el análizador de la construcción de nodos, se utiliza una clase Builder 2 que se encarga de construir el árbol sintáctico a partir de las indicaciones del analizador sintáctico. class Parser { public: virtual bool parse(scanner&, Builder&, SymbolTable &) = 0; ; class ParserProg: public Parser { public: virtual bool parse(scanner&, Builder&, SymbolTable &); ; class ParserCode: public Parser { public: virtual bool parse(scanner&, Builder&, SymbolTable &); ; class ParserArg: public Parser { public: virtual bool parse(scanner&, Builder&, SymbolTable &); ; class Builder { public: virtual void addcode(code*); virtual ProgramNode* getprogram(); ; protected: Builder(); 2 Se ha utilizado el patrón de diseño Builder [Gamma 95]

19 Ejemplo de intérprete de lenguaje recursivo 1.7. Ejemplo de intérprete de lenguaje recursivo En este apartado se describe la implementación de un intérprete de un sencillo lenguaje recursivo. Se describen tres posibles diseños indicando las ventajas e inconvenientes de cada uno Definición del lenguaje El lenguaje consta de dos categorías sintácticas fundamentales: expresiones y órdenes, que tienen la siguiente estructura: <comm> ::= while <expr> do <comm> if <expr> then <comm> else <comm> <var> := <expr> <comm> ; <comm> <expr> ::= <expr> <binop> <expr> <var> <integer> <binop> ::= + - * / = < Diseño imperativo simple La implementación imperativa simple consistiría en utilizar una instrucción de selección que, dependiendo del tipo de instrucción, ejecute una porción de código determinada. El código tendría la siguiente apariencia: void exec(context &c) { switch (c.code) { case WHILE:... case IF: Como en el lenguaje intermedio, la representación interna de las instrucciones se puede realizar mediante una unión. El diseño imperativo tiene como principal ventaja la eficiencia y sencillez de aplicación. Sin embargo, su utilización puede perjudicar la eficiencia de la representación interna de las instrucciones, desperdiciando memoria para instrucciones pequeñas. Otras desventajas son la dificultad para añadir instrucciones sin modificar el código anterior y la falta de seguridad (es posible acceder a campos de la unión equivocados sin que el compilador lo detecte Diseño Orientado a Objetos simple La representación de las instrucciones puede realizarse mediante una clase abstracta Comm que contiene un método exec que indica cómo ejecutar dicha instrucción en un contexto determinado. abstract class Comm { void exec(context ctx); Cada una de las instrucciones será una subclase de la clase abstracta que definirá el método exec e incluirá los elementos necesarios de dicha instrucción. class While extends Comm { Expr e; Comm c; void exec(context ctx) { for (;;) { Bvalue v = (Bvalue) e.eval(ctx); if (!v.b) break; c.exec(ctx); class If extends Comm { Expr e; Comm c1, c2; void exec(context ctx) { Bvalue v = (Bvalue) e.eval(ctx);

20 Ejemplo de intérprete de lenguaje recursivo if (v.b) c1.exec(ctx); c2.exec(ctx); class Seq extends Comm { Comm c1, c2; void exec(context ctx) { c1.exec(ctx); c2.exec(ctx); class Assign extends Comm { String name; Expr e; void exec(context ctx) { Value v = e.eval(ctx); ctx.update(name,v); class Skip extends Comm { void exec(context ctx) { En el caso de las expresiones, se define una clase abstracta con un método de evaluación de expresiones en un contexto. Obsérvese que el método de evaluación devuelve un valor. abstract class Expr { Value eval(context ctx); class BinOp extends Expr { Operator op; Expr e1,e2; Value eval(context ctx) { Value v1 = e1.eval(ctx); Value v2 = e2.eval(ctx); return op.apply(v1,v2); class Var extends Expr { String name; Value eval(context ctx) { return ctx(lookup(name)); class Const extends Expr { int n; Value eval(context ctx) { return n; En el código anterior, se utilizan varias funciones auxiliares del contexto: Value lookup(string) busca el valor de un nombre void update(string, Value) actualiza el valor de un nombre Utilización del patrón visitor El problema del esquema anterior es que el código correspondiente a la interpretación está disperso en cada una de las clases del árbol sintáctico. En la práctica, la construcción de un procesador de un lenguaje puede requerir la realización de varias fases: impresión, generación de código, interpretación, chequeo de tipos, etc. Mediante el patrón visitor es posible concentrar el código de cada fase en una sola clase. Para ello, se define un método visita en cada uno de los tipos de nodos del árbol (instrucciones o expresiones). Lo único que realiza dicho método es identificarse a sí mismo invocando el método correspondiente de la clase visitante. abstract class Comm { public Object visita(visitor v);

21 Ejemplo de intérprete de lenguaje recursivo class While extends Comm { public Expr e; public Comm c; public Object visita(visitor v) { return v.visitawhile(this); class If extends Comm { public Expr e; public Comm c1, c2; public Object visita(visitor v) { return v.visitaif (this); class Seq extends Comm { public Comm c1, c2; public Object visita(visitor v) { return v.visitaseq(this); class Assign extends Comm { public String name; public Expr e; public Object visita(visitor v) { return v.visitaassign(this); class Skip extends Comm { Object visita(visitor v) { return v.visitaskip(this); En el caso de las expresiones, se realiza el mismo esquema. abstract class Expr { public abstract Object visita(visitor v); class BinOp extends Expr { public Operator op; public Expr e1,e2; public Object visita(visitor v) { return v.visitabinop(this); class Var extends Expr { public String name; public Object visita(visitor v) { return v.visitavar(this); class Const extends Expr { public int n; public Object visita(visitor v) { return v.visitaconst(this);

22 Ejemplo de intérprete de lenguaje recursivo Se define una clase abstracta Visitor cuyas subclases representarán posibles recorridos. La clase incluye métodos del tipo Object visitax(x n) para cada tipo de nodo X del árbol sintáctico. abstract class Visitor { Object visitawhile(while w); Object visitaif(if i); Object visitaseq(seq s); Object visitaassign(assign a); Object visitaskip(skip s); Object visitabinop(binop b); Object visitavar(var v); Object visitaconst(const c); A continuación se define el intérprete como un posible recorrido del árbol sintáctico y por tanto, una subclase de Visitor. class Interp extends Visitor { // Aquí se pueden definir los elementos del contexto (Tabla, Memoria, etc.) Object visitawhile(while w) { for (;;) { BValue v = (BValue) w.e.visita(this); if (!v.b) break; w.c.visita(this); Object visitaif(if i){ BValue v = (BValue) i.e.visita(this); if (!v.b) i.c1.visita(this); else i.c2.visita(this); Object visitaseq(seq s){ s.c1.visita(this); s.c2.visita(this); Object visitaassign(assign a) { Value v = (Value) a.e.visita(this); update(a.name,v); Object visitaskip(skip s) { Object visitabinop(binop b) { Value v1 = (Value) b.e1.visita(this); Value v2 = (Value) b.e2.visita(this); return (b.op.apply(v1,v2)); Object visitavar(var v){ return lookup(v.name); Object visitaconst(const c) { return c.n; // Función de ejecución de órdenes Object exec(comm c) { c.visita(this); Las principales ventajas de este diseño son: Todo el código del intérprete está localizado en una clase, facilitando las modificaciones. Pueden añadirse nuevos tipos de recorridos como generación de código, impresión, chequeo de tipos, etc. de forma sencilla. Cada tipo de recorrido será una subclase de Visitor. Al añadir un tipo de recorrido, no es necesario modificar el código del árbol sintáctico. Sin embargo, este diseño también tiene varias desventajas

23 Ejemplo de intérprete de lenguaje recursivo Es más difícil añadir nuevos tipos de nodos al árbol sintáctico. Al hacerlo, habría que modificar todas las subclases de Visitor. Se debe exponer el interior de los nodos del árbol sintáctico, perjudicando la encapsulación. Todos los métodos del tipo Object visitax( X...) devuelven un valor Object obligando a realizar ahormados que pueden acarrear problemas de seguridad