Error! Marcador no definido. Error! Marcador no definido. Error! Marcador no definido. Error! Marcador no definido.

Transcripción

1 Índice. Introducción Tipos de traductores Autómatas Autómatas finitos (FA finite automata) Autómatas finitos deterministas (DFA deterministic finite automata) Autómatas finitos no deterministas (NFA nondeterministic finite automata)..... Autómata de Pila (PDA push-down automaton) Autómatas de pila Gramáticas formales Gramática Regular Gramática libre de contexto (CFG Context Free Grammar) Fases de un compilador Análisis Léxico.... Definición de un reconocedor de cadenas no trivial..... Las operaciones regulares Definición formal de una expresión regular Programar sistemáticamente el reconocedor en lo referente a la obtención del autómata, almacenarlo eficientemente y manejar adecuadamente el archivo fuente Conversión de una expresión regular a un autómata finito no determinista (NFA) Conversión de un autómata finito no determinista (NFA) a su correspondiente autómata finito determinista (DFA) Codificación de un DFA en pseudocódigo Análisis sintáctico Construcción de tablas parse LR()... 5 Algoritmo para construir el FA que servirá de base para la tabla parse LR() Análisis sintáctico LALR() Primer principio del análisis sintáctico LALR() Segundo principio del análisis sintáctico LALR() Análisis sintáctico LR() canónico Autómatas finitos de elementos LR() Definición de transiciones LR() (parte ) Conjuntos primero Análisis Léxico Planteamiento del problema Solución... Error! Marcador no definido. 4.. Análisis... Error! Marcador no definido. 4.. Diseño... Error! Marcador no definido Expresiones regulares y NFA's... Error! Marcador no definido DFA... Error! Marcador no definido. 4.3 Implementación... Error! Marcador no definido main.cpp (primera parte)... Error! Marcador no definido.

2 4.3. Código referente al análisis léxico (compilador.cpp primera parte). Error! Marcador no definido Implementación alternativa en Flex... Error! Marcador no definido. 5. Análisis sintáctico Planteamiento del problema Solución... Error! Marcador no definido. 5.. Análisis... Error! Marcador no definido. 5.. Diseño... Error! Marcador no definido. 5.3 Implementación... Error! Marcador no definido main.cpp... Error! Marcador no definido compilador.ui... Error! Marcador no definido compilador.h... Error! Marcador no definido Código referente al análisis sintáctico (compilador.cpp parte ). Error! Marcador no definido Implementación alternativa Bison... Error! Marcador no definido.

3 Índice de figuras Fig. : Proceso de interpretación... 9 Fig. : Un compilador... 9 Fig. 3: Árbol sintáctico para... 9 Fig. 4: Traductor híbrido para... 0 Fig. 5: DFA que reconoce cadenas que contienen... Fig. 6: NFA que reconoce a la cadena vacía o cadenas que tienen... Fig. 7: PDA que reconoce lenguajes del tipo... 4 Fig. 8: Ejemplo de reglas gramaticales... 5 Fig. 9: Ejemplo de reglas permitidas en una gramática regular (izquierda) y de reglas no permitidas en una gramática regular (derecha)... 5 Fig. 0: Ejemplo de una CFG... 6 Fig. : Fases de un compilador... 7 Fig. : Árbol sintáctico de la expresión a [ index ] Fig. 3: Árbol semántico (corregir este árbol) de la expresión a [ index ] Fig. 4: Optimizador de código fuente... 9 Fig. 5: código objeto en ensamblador generado a partir de la representación intermedia de la Fig Fig. 6: Código objeto optimizado... 0 Fig. 7: Un pequeño ejemplo de un programa fuente... Fig. 8: un pequeño ejemplo de un programa fuente con un error léxico... Fig. 9: un pequeño ejemplo de un programa fuente sin error léxico... Fig. 0: Un NFA que reconoce a la cadena vacía o cadenas que tienen cualquier número de a s5 Fig. : Construcción de un NFA para reconocer A A... 7 Fig. : Construcción de M para reconocer A A... 8 * Fig. 3: Construimos M para que reconozca A... 9 Fig. 4: Autómata que reconoce a z Fig. 5: Autómata que reconoce a y Fig. 6: Autómata que reconoce a x Fig. 7: Autómata que reconoce z y * Fig. 8: Autómata que reconoce ( z y)... 3 Fig. 9: Autómata que reconoce... 3 Fig. 30: Ejemplo de un NFA Fig. 3: Estado inicial del DFA q Fig. 3: Segundo estado del DFA Fig. 33: Siguiente estado del DFA * Fig. 34: NFA correspondiente a ( z y) x Fig. 35: Estado inicial del DFA Fig. 36: Nuevo estado del DFA generado por la transición x del NFA en q Fig. 37: Estado 3 del DFA Fig. 38: Estado 4 del DFA Fig. 39: Agregación de estado de ERROR Fig. 40: Transición del estado 3 al estado... 40

4 Fig. 4: Transición del estado 3 a él mismo Fig. 4: Transición del estado 3 al estado Fig. 43: Transición del estado 4 añ estado... 4 Fig. 44: Algún título... 4 Fig. 45: Transición del estado 4 a él mismo... 4 Fig. 46: DFA representando la sintaxis de un nombre de variable (identificador)... 4 Fig. 47: PDA que reconoce lenguajes del tipo Fig. 48: Estados del PDA Fig. 49: Introducción de la primera transición ( q 0,, ; p, #) Fig. 50: Introducción de la segunda transición ( p,, ; q, S) Fig. 5: Introducir transiciones por cada regla de producción Fig. 5: Introducir una transición por cada símbolo terminal Fig. 53: PDA para la gramática dada Fig. 54: Gramática Fig. 55: PDA del Ejercicio Fig. 56: PDA del ejercicio Fig. 57: PDA del ejercicio Fig. 58: Establecimiento de 4 estados Fig. 59: Primeras dos transiciones Fig. 60: Una transición por cada símbolo terminal... 5 Fig. 6: Una transición por cada regla gramatical... 5 Fig. 6: Última transición... 5 Fig. 63: Gramática... 5 Fig. 64: Estado inicial del FA cerradura de S' S Fig. 65: Segundo estado Fig. 66: Tercer estado Fig. 67: Estado 4 del AF Fig. 68: Estado 5 del AF Fig. 69: Transición x Fig. 70: Transición del estado 3 al estado 4 con Fig. 7: Ultimo estado del AF Fig. 7: LR(0) Fig. 73: Otra figura Fig. 74: DFA de A ( A) a Fig. 75: LR() Fig. 76: Algún título Fig. 77: Algún título Fig. 78: NFA que reconoce una letra... Error! Marcador no definido. Fig. 79: NFA que reconoce un dígito... Error! Marcador no definido. Fig. 80: NFA que reconoce un identificador... Error! Marcador no definido. Fig. 8: NFA que reconoce un dígito... Error! Marcador no definido. Fig. 8: NFA que reconoce un punto y coma... Error! Marcador no definido. Fig. 83: NFA que reconoce el operador de asignación (:=)... Error! Marcador no definido. Fig. 84: NFA que reconoce un paréntesis abierto... Error! Marcador no definido. Fig. 85: NFA que reconoce un paréntesis cerrado... Error! Marcador no definido. Fig. 86: Autómata finito que reconoce algún operador de suma.. Error! Marcador no definido.

5 Fig. 87: Autómata finito que reconoce algún operador de multiplicación... Error! Marcador no definido. Fig. 88: Autómata Finito no Determinista... Error! Marcador no definido. Fig. 89: Autómata Finito Determinista... Error! Marcador no definido. Fig. 90: Algún título... Error! Marcador no definido. Fig. 9: Interfaz de usuario... Error! Marcador no definido.

6 Índice de tablas Tabla : Salida del analizador léxico para la expresión... 8 Tabla : Tokens del programa fuente de la Fig Tabla 3: Resultado de la función de transición para el NFA de la Fig Tabla 4: Secuencia de instrucciones sugerida por el diagrama de transición de la Fig Tabla 5: Tabla de transición construida del diagrama de transición de la figura Tabla 6: Análisis léxico basado en la Tabla 4 de transiciones Tabla 7: Tabla parse LL() para la gramática de la izquierda Tabla 8: Rutina parse LL() genérica Tabla 9: Tabla LALR() Tabla 0: Tabla LR() Tabla : Algoritmo Tabla : Algún título Tabla 3: Tabla de cerraduras de los elementos del NFA de lafig Error! Marcador no definido. Tabla 4: Código escrito en Flex... Error! Marcador no definido. Tabla 5: Gramática... 6 Tabla 6: Gramática re-escrita... Error! Marcador no definido. Tabla 7: Tabla parse (parte )... Error! Marcador no definido. Tabla 8: Tabla parse (parte )... Error! Marcador no definido. Tabla 9: Tabla parse (parte 3)... Error! Marcador no definido. Tabla 0: Tabla parse (parte 4)... Error! Marcador no definido. Tabla : Código correspondiente al análisis sintáctico escrito en Bison... Error! Marcador no definido.

7 . Introducción Idealmente, un curso de compiladores debería llevarse en semestres. Durante el primero de éstos, se revisarían con detenimiento las técnicas asociadas a los diferentes tipos de análisis que involucra la construcción de un compilador: autómatas de estados finitos y gramáticas regulares para el análisis léxico, y autómatas de pila y gramáticas libres de contexto para el análisis sintáctico y semántico. Durante el segundo semestre, se revisarían las técnicas asociadas a la generación de código: grafos dirigidos acíclicos y código de tres direcciones para la generación de código intermedio, asignación de registros y grafos de flujo para la generación de código, y transformaciones para la optimización de código, entre otras. Además, hay que mencionar que en ambos semestres se deben revisar las técnicas para la construcción de las tablas de literales y de símbolos, así como para el módulo de manejo de errores pues todos ellos guardan una estrecha relación con cada una de las fases de análisis y síntesis (esta última es la encargada de la generación de código). En la realidad, en general, un curso de compiladores se lleva en sólo un semestre. Esto hace que el material del curso se tenga que revisar rápidamente y que con frecuencia dicho material no pueda cubrirse en su totalidad. Hay que mencionar también que un curso de compiladores se enseña a los estudiantes que están cursando los últimos semestres de su carrera pues se necesitan varios cursos pre-requisito para entenderlo: matemáticas discretas, algoritmos y estructuras de datos, lenguajes de programación, programación de sistemas, teoría de la computación, arquitectura de computadoras e ingeniería de software, como mínimo. En la medida de lo posible, el material expuesto en el presente libro será autocontenido; esto con la finalidad de revisar más rápidamente los temas aquí incluidos. Sin embargo, es necesario hacer hincapié en que, dada la complejidad de un curso de esta naturaleza, el estudiante lo aprovechará más si realiza por su cuenta los ejercicios de cada capítulo así como si refuerza cada tema consultando fuentes complementarias. Por si esto fuera poco, un curso de compiladores no sólo exige al estudiante desarrollar sus saberes teóricos sino también los prácticos: para entender con mayor claridad el poder de un compilador, es necesario no sólo comprender los conceptos teóricos a partir de los cuales se construye sino además implementar dichos conceptos que lo harán darse cuenta que, al menos en este tópico en particular, la teoría no está muy alejada de la práctica. Hay que decir, finalmente, que la construcción de un compilador comercial involucra un equipo de al menos decenas de personas: desarrolladores, diseñadores, ingenieros y arquitectos de software, testers, etc. Es por esto que un curso de compiladores a nivel licenciatura sólo puede aspirar a proveer al estudiante con las técnicas básicas necesarias para la construcción de un compilador sencillo que pueda mostrar el potencial de dichas técnicas en la construcción de un compilador comercial. Si el estudiante entiende claramente todas estas técnicas, no le será muy difícil involucrarse en el proceso de construcción de un compilador de este tipo, sea cual sea su participación. En este capítulo, revisaremos brevemente los conceptos fundamentales sobre compiladores y veremos cómo se aplican en cada una de las fases de un compilador. En cierta medida, es como un resumen del resto del libro: presentaremos cómo un programa en código fuente es traducido a su equivalente en código objeto, el cual puede ser entendido y ejecutado por la computadora en cuestión. El resto de los capítulos exponen de manera más detallada cada una de las técnicas para lograr este objetivo.. Tipos de traductores Un lenguaje de programación sirve como canal de comunicación entre un usuario humano y una computadora. Es decir, si un humano quiere implementar la solución de un

8 problema específico en una computadora, éste debe usar un lenguaje de programación. Hoy en día es tan común la noción de lenguaje de programación (generalmente de alto nivel) que nos olvidamos de que la computadora no entiende directamente dicho lenguaje: el lenguaje que ésta entiende está formado por largas cadenas de ceros y unos. Para que la computadora entienda y ejecute las instrucciones contenidas en un programa escrito en algún lenguaje de programación, dichas instrucciones deben ser traducidas al lenguaje que sí entiende la máquina: el lenguaje binario. Podríamos programar una computadora usando directamente estas largas secuencias de ceros y unos pero esto involucra una ardua y difícil tarea que hace muy complicada la interacción con ella. La idea fundamental es entonces construir un traductor que tome como entrada un programa escrito en un lenguaje de programación (frecuentemente de alto nivel) y lo convierta en una versión equivalente en lenguaje de máquina. El lenguaje de máquina es una representación abreviada de las secuencias de ceros y unos usando códigos numéricos, los cuales representan operaciones en la máquina anfitrión. Un lenguaje de máquina representa el más bajo nivel de un lenguaje de programación. Por ejemplo, C representa la instrucción para mover el número a la ubicación 0000 (en sistema hexadecimal) en los procesadores Intel 8x86 que se utilizan en las PC de IBM En general, al programa de entrada se le conoce como programa fuente y al programa de salida como programa objeto o programa destino. Es importante señalar que el programa fuente está escrito en un lenguaje fuente (comúnmente de alto nivel) y que el programa objeto pertenece a un lenguaje objeto (que bien puede ser lenguaje máquina, lenguaje ensamblador o incluso otro lenguaje de alto nivel). Un compilador que toma como entrada un programa fuente escrito en un lenguaje de alto nivel y produce como salida un programa objeto escrito también en un lenguaje de alto nivel se le conoce como source-to-source. En este libro construiremos un compilador para un lenguaje de programación sencillo cuyos programas objeto estarán en lenguaje ensamblador. Esta práctica es útil ya que no sólo es más fácil producir programas en ensamblador (pues se evita generar código para la arquitectura de una computadora en particular) sino que también es más fácil depurar los programas objeto escritos en este lenguaje. Nos concentraremos entonces en la generación de código en lenguaje ensamblador que puede a su vez ser leído por un programa ensamblador (de los cuales existen varias versiones que pueden descargarse de la red e instalarse de forma gratuita) y así éste traducirlo a código máquina. De hecho, algunos diseñadores de lenguajes de programación van más allá de esta práctica al construir compiladores source-to-source para programas cuyo código fuente es traducido a código que está en algún lenguaje de alto nivel (como C). Así, ellos aprovechan los compiladores existentes que reciben como entrada el código escrito en este lenguaje objeto y pueden revisar rápidamente el funcionamiento del lenguaje de su propio diseño sin tener que preocuparse demasiado por los detalles de la generación de código en lenguaje máquina. Aunque por el momento hemos hablado solamente de compiladores como traductores, existen también otros tipos: ensambladores e intérpretes. Un ensamblador (assembler) es un traductor cuya entrada es un programa escrito en lenguaje ensamblador (assembly language) y cuya salida es un programa escrito en lenguaje de máquina. Una posible secuencia de código en lenguaje ensamblador es la siguiente: MOV R0, index MUL R0, MOV R, &a ADD R, R0 ;; valor de index R0 ;; duplica el valor en R0 ;; dirección de a R ;; sumar R0 a R

9 MOV *R, 6 ;; constante 6 dirección en R Un intérprete es también un traductor que no genera código objeto (como lo hace un compilador) sino que ejecuta el programa fuente inmediatamente. En otras palabras, un intérprete procesa y ejecuta al mismo tiempo el programa fuente y los datos de entrada para éste. La Fig. muestra a grandes rasgos como funciona un intérprete. Fig. : Proceso de interpretación Como puede apreciarse, el proceso de traducción usando un intérprete se realiza cada vez que éste es ejecutado. Por ende, en general, los intérpretes tienden a ser mucho más lentos que los compiladores (hasta por un factor de 0 o más) [ref. Louden, p. 5]. Sin embargo, por otro lado, un intérprete puede por lo regular proveer un mejor diagnóstico de errores que un compilador toda vez que aquél ejecuta el programa fuente instrucción por instrucción. Un compilador es, como mencionamos, un traductor que toma como entrada un programa fuente y lo convierte a un programa objeto o destino. Este programa objeto es una traducción fiel del programa fuente escrita en lenguaje máquina, lenguaje ensamblador o incluso en algún otro lenguaje de programación. Una vez generado el programa objeto, éste es ejecutado al recibir sus respectivas entradas (ver Fig. y Fig. 3). := suma + deposito_inicial interes * 60 Fig. : Un compilador Fig. 3: Árbol sintáctico para De haber errores en el programa fuente, el compilador deberá reportarlos y, de ser posible, corregirlos. En comparación con un intérprete, un compilador traduce una sola vez el programa fuente (el cual se convierte, después del proceso de traducción, en el programa objeto). Así, cada vez que se ejecute el correspondiente programa objeto, ya no es necesario hacer de nuevo otra traducción, lo cual ahorrará tiempo significativo de procesamiento. Es por esta razón que un compilador es en general mucho más rápido que un intérprete. En la sección.4 mencionamos brevemente las fases de un compilador para que se pueda apreciar, entre otras cosas, la complejidad en el proceso de traducción. El resto del libro (a partir del capítulo ) revisa con detalle cada una de estas fases. Es importante mencionar que existen traductores híbridos, los cuales combinan el proceso de interpretación con el de compilación. Los traductores para el lenguaje de programación Java son un ejemplo de este tipo: un programa fuente escrito en Java puede compilarse en una representación intermedia llamada bytecodes que después es interpretada

10 por una máquina virtual. El beneficio de este tipo de traductores es que la representación intermedia puede compilarse en una computadora e interpretarse en otra distinta (revisar el concepto de portabilidad). La Fig. 4 muestra un traductor híbrido. Expresion de asignacion identificador := expresion identificador Expresion aditiva posicion expresion + expresion identificador expresion * expresion inicial identificador numero velocidad 60 Fig. 4: Traductor híbrido para Finalmente, para cerrar esta sección, hay que decir que hay otros programas relacionados estrechamente con los compiladores: preprocesadores, ligadores, cargadores, editores y depuradores, entre otros. Todos estos programas complementan la labor de un compilador y cuyas tareas van desde facilitar al programador la escritura del programa fuente hasta crear el programa objeto y determinar los errores de ejecución en dicho programa. Para mayores detalles sobre dichos programas, se sugiere al lector consultar [ref. Louden y dragón].. Autómatas Aunque en la sección.4 mencionaremos las fases de las que típicamente consta un compilador, en esta sección aprovechamos para revisar brevemente los modelos de cómputo que se usan en las fases correspondientes al análisis: autómatas de estados finitos para el análisis léxico y autómatas de pila para el análisis sintáctico y semántico. Por el momento, no entramos en detalles sobre estos modelos pero sí presentamos sus correspondientes definiciones formales para que el lector aprecie que un compilador está basado en fundamentos matemáticos sólidos. En el capítulo presentamos minuciosamente a los autómatas finitos y sus correspondientes lenguajes y gramáticas asociados: lenguajes y gramáticas regulares. En los capítulos 3 y 5 revisamos a los autómatas de pila y sus correspondientes lenguajes y gramáticas asociadas: lenguajes y gramáticas libres de contexto... Autómatas finitos (FA finite automata) Los autómatas de estados finitos, o simplemente autómatas finitos, son el modelo más sencillo de cómputo. Esto no significa que tienen poco poder: de hecho, los autómatas finitos son poderosos reconocedores de patrones en los datos. Esto es precisamente lo que queremos hacer en primer lugar con el programa fuente: reconocer en él ciertos patrones que nos permitan clasificarlos en tokens (los tokens son conjuntos de caracteres que forman una entidad).

11 Ejemplos típicos de tokens son: nombres de variables (o identificadores), signos de agrupación (como paréntesis, corchetes y llaves), símbolos de operaciones (suma, resta, multiplicación, división), signos de puntuación (punto, coma, punto y coma) y números (enteros, reales), entre otros. Para clarificar el concepto de token, en la sección.4 presentamos un ejemplo de cómo un analizador léxico divide el programa fuente en dichos elementos. Además, en el capítulo, revisaremos paso a paso cómo usar los autómatas finitos (y modelos equivalentes como las expresiones y gramáticas regulares) para este fin. Por el momento, daremos las definiciones formales de un FA para que el lector empiece a apreciar los fundamentos matemáticos que soportan la construcción de un compilador. La teoría sobre autómatas finitos suele revisarse en un curso de matemáticas discretas, de teoría de la computación o de programación de sistemas. De cualquier manera, aquí repasaremos estos conceptos pero nos concentraremos, en el capítulo, en cómo usarlos para construir un analizador léxico. Un FA puede ser de dos tipos: determinista (DFA) o no determinista (NFA). Aunque estas definiciones difieren una de la otra principalmente en la función de transición, el poder de cómputo de cada uno de estos tipos es equivalente: aquellas cadenas de símbolos que reconoce uno las reconoce el otro y viceversa. De hecho, en el capítulo, revisamos un par de teoremas (y sus respectivas demostraciones) que nos permiten construir, para cada NFA, su equivalente DFA. En las secciones siguientes, damos la definición formal de DFA y NFA respectivamente.... Autómatas finitos deterministas (DFA deterministic finite automata) Un DFA es una 5-tupla ( Q,,, q0, F) donde: Q es un conjunto finito llamado estados es un conjunto finito llamado alfabeto : QQ es la función de transición q 0 Q es el estado inicial F Q es el conjunto de estados de aceptación Un ejemplo de un DFA aparece en la Fig. 5 Fig. 5: DFA que reconoce cadenas que contienen al menos a s (sin importar el orden) Como puede observarse, este DFA contiene 3 estados (q, q, q 3 ), elementos en el alfabeto (a, b), un estado inicial (q, el cual está marcado por la flecha viniendo de ningún lugar), un estado final (q 3, el cual se identifica con un doble círculo) y una función de transición determinista: para cada entrada compuesta por cualquier combinación entre un estado y un elemento del alfabeto, existe una única salida (un estado). Esta función de transición es la que caracteriza a los DFA. En el capítulo revisaremos con detalle cada una de las partes de dicha

12 función. En la siguiente sección veremos que la función de transición que caracteriza a los NFA contiene un ingrediente distinto al de los DFA: el no determinismo.... Autómatas finitos no deterministas (NFA nondeterministic finite automata) Un NFA es una 5-tupla ( Q,,, q0, F) donde: Q es un conjunto finito de estados es un alfabeto finito :Q P (Q ) es la función de transición q 0 Q es el estado inicial F Q es el conjunto de estados de aceptación Un ejemplo de un DFA aparece en la Fig. 6 Fig. 6: NFA que reconoce a la cadena vacía o cadenas que tienen cualquier número de a s Como puede observarse, este NFA contiene 4 estados (q, q, q 3, q 4 ), elemento en el alfabeto (a), un estado inicial (q ), un estado final (q 4 ) y una función de transición no determinista: en contraste con un DFA, un NFA no tiene necesariamente que tener, para cada entrada compuesta por cualquier combinación entre un estado y un elemento del alfabeto, una única salida (un estado). De hecho, la definición de la función de transición para un NFA cualquiera contempla como salida un conjunto de estados (incluido por supuesto el conjunto vacío). Es por esto que esta función de transición incluye la definición del conjunto potencia sobre el conjunto de estados así como la posibilidad de tener la cadena vacía como entrada en uno de los argumentos de dicha función. Esto significa, para el primer caso (la definición del conjunto potencia sobre el conjunto de estados), que dados como entrada un estado y un elemento del alfabeto (incluida la cadena vacía), la salida es un conjunto de estados: esta característica es la que define principalmente a la propiedad de no determinismo. Por ejemplo, para nuestro NFA de la Fig. 6, si el autómata se encuentra en el estado q, éste puede saltar tanto al estado q como al estado q 4 con la cadena vacía. Para el segundo caso (la posibilidad de tener la cadena vacía como entrada), tener transiciones con la cadena vacía como entrada significa que el autómata puede pasar de un estado a otro sin tener que leer absolutamente nada de la cadena de entrada. Además, un NFA permite que no necesariamente para cada combinación de entrada (estado x elemento del alfabeto) exista una salida determinada. Para esta misma figura podemos apreciar que no existe transición (por mencionar una de ellas) cuando se está en el estado q y se tiene una a. Las implicaciones de estas características las revisaremos con detalle en el capítulo. En esta sección sólo queremos introducir algunos conceptos fundamentales que servirán de base para construir un analizador léxico. Para finalizar dicha sección, debemos decir nuevamente que usaremos la teoría de autómatas finitos para construir un analizador léxico pasando por los siguientes pasos: Expresión regular NFA DFA Programa

13 A partir de una expresión regular (la cual revisaremos en el capítulo y que sirve para representar los tokens de un programa fuente), podemos construir un NFA que represente esa expresión; después, a partir de ese NFA, se construye su DFA equivalente, el cual sirve para codificar, en algún lenguaje de programación, el reconocedor léxico para ese token en específico. Una vez más, en el capítulo revisaremos a detalle cada uno de estos pasos... Autómata de Pila (PDA push-down automaton) Los autómatas de pila tienen un componente extra respecto a los FA (sean deterministas o no deterministas): una memoria tipo pila. Los FA en general sólo cuentan con sus estados como memoria; es por ello que los FA son el modelo más sencillo de cómputo. Cada estado en un FA sólo recuerda el último elemento del alfabeto con el cual se llegó a dicho estado. Si necesitáramos que el autómata recuerde una secuencia de estos elementos, es necesario entonces agregarle explícitamente una memoria. Para los PDA, la memoria es de tipo pila (LIFO last input first output). Con este componente extra, es posible reconocer lenguajes que no pueden ser reconocidos por los FA. A los lenguajes aceptados/reconocidos por un PDA se les conoce como lenguajes libres de contexto. Un ejemplo de un PDA con su correspondiente lenguaje libre de contexto que reconoce se presenta en la Fig. 7. El lenguaje reconocido por este autómata es (con ), es decir, dicho PDA reconoce cadenas conformadas por un número específico de ceros (denotado por ) seguido del mismo número de unos. Es importante mencionar que no existe un FA que reconozca dicho lenguaje: es aquí donde queda de manifiesto su limitación para reconocer lenguajes que no son regulares. Por supuesto que se revisarán a detalle los conceptos de lenguajes/gramáticas regulares y libres de contexto en los capítulos y 3 respectivamente. Por el momento, el lector puede intentar construir un FA que reconozca este lenguaje. Al intentarlo, podrá notar que lo mejor que podrá hacer es construir un FA con instancias específicas de este lenguaje:,, etc., pero no logrará construir un solo NFA que pueda contender con el caso general; i.e., con cualquier valor de n. Dicho sea de paso, cuando, entonces la cadena resultante es la cadena vacía. Esta cadena cumple con la condición que impone este lenguaje: un número específico de ceros (en este caso ninguno) seguido del mismo número de unos. Entonces, para poder reconocer este lenguaje, se necesita un elemento extra: la pila. Los PDA son la base para construir analizadores sintácticos. Para el caso concreto de un compilador, un analizador sintáctico sirve para verificar que la estructura del programa fuente sea la correcta; i.e., que el programa fuente esté correctamente escrito. Como los lenguajes de programación están basados en gramáticas libres de contexto, y éstas son definiciones equivalentes a los autómatas de pila, éstos entonces pueden ser usados para reconocer que la estructura de un programa fuente (escrito en algún lenguaje de programación) sea correcta. En el capítulo 3 revisamos cómo se logra esto. Por el momento, veamos la definición formal de un PDA para que el lector empiece a familiarizarse con este tipo de autómata.... Autómatas de pila Un PDA es una 6-tupla (Q,,,, q 0, F) donde Q,, y F son todos conjuntos finitos y: Q es el conjunto finito de estados. es el alfabeto de entrada. es el alfabeto de la pila. : Q P (Q ) es la función de transición.

14 q 0 Q es el estado inicial. F Q es el conjunto de estados de aceptación. 0, ε 0 q ε, ε $ q, 0 ε q4 ε, $ ε q3 Fig. 7: PDA que reconoce lenguajes del tipo, 0 ε Como puede observarse en la definición, un PDA consta de 6 partes. La parte extra con respecto a los FA es la pila, la cual acepta un alfabeto específico que bien puede ser diferente al alfabeto de entrada. Por ejemplo, en el PDA de la Fig. 7, el alfabeto de entrada * +, mientras que el alfabeto de la pila es * +. Por otro lado, tenemos a la función de transición que, debido a la pila, se vuelve más compleja: la entrada de dicha función está formada por un elemento de los estados del autómata, un elemento del alfabeto de entrada (incluida la cadena vacía) y uno de la pila respectivamente (incluida la cadena vacía), y la salida por un elemento en el conjunto de estados y un elemento en la pila (incluida la cadena vacía). Aunque revisaremos a detalle los PDA en el capítulo 3, podemos mencionar aquí brevemente el significado de la función de transición. Tomando como referencia a la Fig. 7, podemos decir por ejemplo que para que el autómata pase del estado al, tienen que cumplirse condiciones: que no se lea nada de la entrada (esto es, que se lea la cadena vacía - representada por ) y que no se lea nada de la pila (representado también por ); el resultado será entonces pasar al estado q desde el estado q modificando el contenido de la pila al meter a ésta el símbolo especial $. Las operaciones de lectura y escritura de la pila se conocen comúnmente como pop y push respectivamente. En el capítulo 3 construiremos un analizador sintáctico a partir de la teoría de autómatas de pila y gramáticas libres de contexto (éstas últimas son una definición equivalente a los PDA). En la siguiente sección, presentamos brevemente los dos tipos de gramáticas que usaremos para el análisis léxico y sintáctico respectivamente: gramáticas regulares y gramáticas libres de contexto..3 Gramáticas formales Antes de hablar de gramáticas formales, debemos mencionar brevemente qué es un lenguaje formal. A diferencia de un lenguaje natural (como el inglés, español, francés, etc.), un lenguaje formal está definido por reglas preestablecidas; ejemplos de lenguajes formales son los lenguajes de programación, el álgebra y la lógica proposicional. Para el caso de un lenguaje de programación, esta característica de los lenguajes formales permite la construcción eficiente de un traductor automático (por ejemplo, un compilador). Para el caso de un lenguaje natural, es la falta de estas reglas preestablecidas la que hace una tarea compleja la construcción de un traductor automático para dicho lenguaje. Son precisamente estas reglas las que conforman principalmente una gramática. Una gramática permite entonces verificar si un enunciado está correctamente escrito dado un lenguaje específico. En nuestro caso, un enunciado será un

15 programa fuente escrito en algún lenguaje de programación. Utilizaremos un tipo de gramática conocida como gramática regular para verificar si los tokens de un programa fuente pertenecen al lenguaje de programación en cuestión; usaremos una gramática conocida como gramática libre de contexto para verificar que la sintaxis de un programa fuente es correcta, de acuerdo a dicho lenguaje de programación. En las siguientes secciones revisamos brevemente las definiciones de una gramática regular y una gramática libre de contexto respectivamente..3. Gramática Regular En general, una gramática consiste en un conjunto de reglas de sustitución o de reescritura conocidas también como producciones. Cada regla aparece en una línea de la gramática conteniendo un símbolo (variable) del lado izquierdo de una flecha y una cadena de símbolos (que pueden ser variables y símbolos terminales) del lado derecho de dicha flecha (Fig. 8). Las variables están comúnmente representadas por letras mayúsculas mientras que los símbolos terminales por letras minúsculas, números o símbolos especiales (los símbolos terminales son análogos al alfabeto de entrada). Además, una de las variables se designa como el símbolo inicial de la gramática y frecuentemente se escribe del lado izquierdo de la primera regla de la gramática. Para el caso de la Fig. 8, la única variable es la letra S, la cual, por ende, coincide con ser el símbolo inicial de la gramática. Los símbolos terminales son las letras x, y, z. Para el caso específico de una gramática regular, las reglas de re-escritura se conforman de acuerdo a las siguientes restricciones: el lado izquierdo de cualquiera de estas reglas de re-escritura debe consistir en un solo no-terminal y el lado derecho debe ser un terminal seguido por un noterminal, un solo terminal o la cadena vacía (representada por o ). Las reglas de la Fig. 8 conforman una gramática regular así como las de la Fig. 9 (izquierda). Las reglas de la derecha de esta última figura no son permitidas en una gramática regular pues no cumplen con las restricciones antes mencionadas. S xs S y S z Fig. 8: Ejemplo de reglas gramaticales Z yx Z x W Reglas permitidas en una gramática regular yw X X Zy YX WyZ Reglas no permitidas en una gramática regular Fig. 9: Ejemplo de reglas permitidas en una gramática regular (izquierda) y de reglas no permitidas en una gramática regular (derecha) Formalmente, una gramática regular es una 4-tupla ( V,, R, S) donde:. V es un conjunto finito, llamado variables (o no-terminales).. es un conjunto finito disjunto de V, llamado terminales. 3. R es un conjunto finito de reglas, con cada regla siendo una variable y una cadena de variables y terminales conforme a las restricciones antes mencionadas. 4. S es la variable inicial.

16 En el capítulo revisaremos la manera detallada de construir la siguiente secuencia: Expresión regular NFA DFA Programa Por el momento, podemos decir que una expresión regular es equivalente a una gramática regular (buscar teorema). Dichas expresiones regulares pueden usarse para definir los tokens de nuestros programas fuente (basados en algún lenguaje de programación específico) y, a partir de éstas, construir un autómata finito que reconozca dichos tokens. Una vez hecho esto, es posible escribir un programa que identifique estos tokens y así verificar que cada uno de éstos sean expresiones válidas dentro de nuestro lenguaje de programación de referencia..3. Gramática libre de contexto (CFG Context Free Grammar) Una CFG es una 4-tupla ( V,, R, S) donde: 5. V es un conjunto finito, llamado variables (o no-terminales). 6. es un conjunto finito disjunto de V, llamado terminales. 7. R es un conjunto finito de reglas, con cada regla siendo una variable a la izquierda de la flecha y una cadena de variables y terminales a la derecha de la flecha. 8. S es la variable inicial. Un ejemplo de una CFG aparece en la Fig. 0. S zmnz M ama M z N bnb N z Fig. 0: Ejemplo de una CFG En el capítulo 3 revisaremos diferentes técnicas para construir un analizador sintáctico basado en una CFG. Por el momento, podemos decir que la mayoría de los lenguajes de programación están basados en una CFG, lo cual nos permite utilizar a los PDA para verificar si un programa fuente, escrito en algún lenguaje de programación específico, está escrito correctamente o, dicho de otra manera, si su estructura gramatical es la correcta..4 Fases de un compilador En esta sección revisaremos brevemente las fases de un compilador (ver Error! No se encuentra el origen de la referencia.).

17 Código fuente Analizador léxico o rastreador Tokens Analizador sintáctico Árbol sintáctico Analizador semántico Tabla de literales Árbol con anotaciones Optimizador de código fuente Tabla de símbolos Código intermedio Manejador de errores Generador de código Código objetivo Optimizador de código objetivo Código objetivo Fig. : Fases de un compilador En primer lugar, el programa fuente (escrito en algún lenguaje de programación determinado) sirve de entrada al analizador léxico o rastreador [ref.]. Como ejemplo, digamos que nuestro programa fuente consta de la siguiente línea: a[index] = 4+ La salida del analizador léxico es un conjunto de tokens que forman parte del lenguaje de programación en cuestión (ver Tabla ): Lexema Tipo de token Un lexema es un conjunto de caracteres del programa fuente que representan una secuencia significativa

18 a identificador [ corchete izquierdo index identificador ] corchete derecho 4 número + operador de adición Número Tabla : Salida del analizador léxico para la expresión, - Como se puede apreciar en la Tabla, el analizador léxico ignora los espacios en blanco. Toca ahora el turno del analizador sintáctico, el cual toma como entrada los tokens producidos en la fase anterior y genera con ellos un árbol sintáctico (ver Fig. ). expresion Expresion de asignacion expresion = expresion Expresion de subindice Expresion aditiva expresion [ expresion ] expresion + expresion Identificador a Identificador index numero 4 numero Fig. : Árbol sintáctico de la expresión a [ index ] 4 Como se puede apreciar en la Fig., la línea de código del presente ejemplo se representa en forma de un árbol, en el cual los nodos internos de dicho árbol representan una operación y los hijos de cada uno de estos nodos representan los argumentos de sus respectivas operaciones. La tercera fase corresponde al analizador semántico, el cual toma como entrada el árbol sintáctico y produce como salida un árbol con anotaciones (ver Fig. 3). Éstas incluyen las declaraciones y la verificación de tipos.

19 Fig. 3: Árbol semántico (corregir este árbol) de la expresión a [ index ] 4 La cuarta fase corresponde al optimizador de código fuente (Fig. 4). Esta fase toma como entrada el árbol con anotaciones y produce como salida una representación intermedia (o código intermedio) entre el programa fuente y el programa objeto, el cual optimiza (siempre que sea posible) las operaciones representadas en el árbol sintáctico. Por ejemplo, en el árbol de la Fig. 4, la rama derecha de dicho árbol es el resultado de colapsar el subárbol derecho de la Fig.. Es importante mencionar que aunque muchas optimizaciones se pueden llevar a cabo directamente sobre el árbol, en varios casos se utiliza una representación lineal de éste conocida como código en tres direcciones (pues contiene hasta tres operandos por instrucción, tal y como sucede en las instrucciones en lenguaje ensamblador). Este tipo de representación se revisará más a detalle en el capítulo 5. Fig. 4: Optimizador de código fuente La quinta fase se refiere a la generación de código. Ésta toma como entrada la representación intermedia generada en la fase anterior y produce su correspondiente código para la máquina objeto. Como mencionamos ya en la sección., en este libro construiremos un compilador para un lenguaje de programación sencillo cuyos programas objeto estarán en lenguaje ensamblador. El código en un hipotético lenguaje ensamblador (considerar agregar código en ensamblador real producido en el compilador de Louden) que se genera a partir de la representación intermedia mostrada en la Fig. 4, se presenta en la Fig. 5. MOV R0, index MUL R0, MOV R, &a ADD R, R0 ;; Valor de index R0 ;; Doble valor en R0 ;; Dirección de a R ;; Sumar R0 a R

20 MOV *R, 6 ;; Constante 6 dirección en R Fig. 5: código objeto en ensamblador generado a partir de la representación intermedia de la Fig. 4 Para este ejemplo específico, &a es la dirección de a y *R significa direccionamiento indirecto de registro, por lo que la última instrucción guarda el valor 6 en la dirección apuntada por R. En el capítulo 6 revisaremos con detalle cómo generar código objeto a partir de una representación intermedia. La última fase propiamente dicha es la optimización de código objeto, la cual intenta mejorar el código que ha sido generado en la fase anterior. La optimización incluye, en términos generales, que se sustituyan instrucciones lentas por otras más rápidas así como que se eliminen operaciones redundantes o innecesarias. La Fig. 6 muestra la optimización del código objeto de la Fig. 5. Optimizador de código objeto MOV R0, index SHL R0 MOV &a[r0], 6 ;; Valor de index R0 ;; doble valor en R0 ;; constante 6 dirección a + R0 Fig. 6: Código objeto optimizado Como se puede apreciar en la Fig. 6, el optimizador ha reducido el número de líneas con respecto al código de la Fig. 5 manteniendo el mismo significado del programa pero reduciendo el tiempo de ejecución. En el capítulo 7 revisaremos con detalle las técnicas para la optimización de código objeto. Para terminar esta sección, es importante mencionar que cada una de las fases de un compilador interactúan con 3 componentes, tal y como lo muestra la Error! No se encuentra el origen de la referencia.: la tabla de literales, la tabla de símbolos y el manejador de errores. Brevemente podemos mencionar que la tabla de literales se utiliza básicamente para almacenar constantes y cadenas que se usan a lo largo de un programa, la tabla de símbolos guarda la información asociada con los identificadores (tales como funciones, variables, constantes y tipos de datos) mientras que el manejador de errores es el módulo que se encarga no sólo de reportar claramente los problemas generados en cada fase del compilador sino también de corregirlos. En los capítulos 3 y 4 veremos algunas técnicas para la recuperación de errores sintácticos y la construcción de tablas de símbolos respectivamente. En el siguiente capítulo, revisaremos las técnicas para construir la primera fase de un compilador: el analizador léxico.

21 . Análisis Léxico En esta unidad revisaremos a detalle las técnicas asociadas a la fase de análisis léxico de un compilador. Básicamente lo que queremos lograr es construir la siguiente secuencia: Expresión regular NFA DFA Programa Recordemos que el trabajo del analizador léxico es dividir en tokens (unidades significativas del lenguaje en cuestión) el programa fuente y reconocer si dichos tokens forman parte del lenguaje para el cual se está llevando a cabo el proceso de traducción. Por ejemplo, dado el siguiente programa: comienza a:=b3; termina; Fig. 7: Un pequeño ejemplo de un programa fuente Nuestro analizador deberá reconocer los siguientes tokens: Lexema comienza a Tipo palabra clave identificador := operador de asignación b3 identificador ; Símbolo especial termina palabra clave Tabla : Tokens del programa fuente de la Fig. 7 Si algún token no estuviera previamente incluido en la definición de nuestro lenguaje de programación como un token válido, entonces la labor de nuestro analizador léxico es detectar a dicho token como inválido. Por ejemplo, podemos observar que el operador de asignación está formado por el símbolo compuesto :=. Si el programa estuviera escrito de la siguiente forma (Fig. 8): comienza a=b3; termina; Fig. 8: un pequeño ejemplo de un programa fuente con un error léxico Y suponiendo que el símbolo = (sin los dos puntos) no ha sido incluido como símbolo válido en la definición de nuestro lenguaje de programación, entonces nuestro analizador léxico deberá producir un mensaje de error cuando encuentra dicho símbolo en el programa fuente. Por otro lado, suponiendo que el paréntesis izquierdo y el paréntesis derecho son símbolos válidos dentro de nuestro lenguaje de programación, entonces en programas como el de la Fig. 9 no existe error léxico: comienza a=b3)); termina

22 Fig. 9: un pequeño ejemplo de un programa fuente sin error léxico La razón es porque al dividir en tokens el programa de la Fig. 9, el analizador léxico reconocerá los paréntesis derechos que aparecen en la línea como tokens válidos. La fase que debería reconocer este error (asumiendo que tener paréntesis que cierran sin sus correspondientes paréntesis que abren es un error estructural del programa fuente) es la fase de análisis sintáctico (los detalles de esta fase los veremos en el capítulo 3). Mientras tanto, revisaremos paso a paso las técnicas necesarias para poder construir la secuencia de arriba y así poder llegar a codificar, como paso final de dicha secuencia, nuestro analizador léxico.. Definición de un reconocedor de cadenas no trivial Antes de definir un reconocedor de cadenas no trivial, necesitamos algunos conceptos que servirán de fundamento para construir nuestra conocida secuencia: Expresión regular NFA DFA Programa En primer lugar, debemos mencionar que las cadenas de caracteres representan bloques de construcción fundamentales dentro de la Ciencia de la Computación. El alfabeto sobre el cual dichas cadenas se encuentran definidas puede variar de aplicación en aplicación. Para nuestro primer propósito (la construcción de un analizador léxico), definimos un alfabeto como un conjunto finito no vacío de símbolos. En general, usamos las letras griegas y para designar alfabetos como se muestra a continuación: * + * + Una cadena definida sobre un alfabeto es una secuencia finita de símbolos tomados de ese alfabeto, usualmente escritos uno junto al otro y no separados por comas. Por ejemplo, si es el alfabeto mostrado arriba, entonces 00 es una cadena sobre dicho alfabeto. Si es el alfabeto mostrado arriba también, entonces abracadabra es una cadena sobe ese alfabeto. Si w es una cadena sobre, la longitud de dicha cadena es el número de símbolos que contiene y se representa como. Es importante mencionar que la cadena que no contiene símbolos (es decir, de longitud cero) se le llama cadena vacía y se escribe comúnmente o. Así que un lenguaje es un conjunto de cadenas definidas sobre un alfabeto que cumplen cierta condición. Por ejemplo, el lenguaje * + definido sobre el alfabeto * + contiene todas las cadenas de y que cumplan con la condición de que dichas cadenas contengan al menos. Así que las cadenas abaaabb y bbbbaaaa son elementos del lenguaje mientras que las cadenas bbbbb y bbbbbabbbb no lo son. Hay que notar que el conjunto de cadenas pertenecientes al lenguaje es infinito. Para nuestro caso específico (análisis léxico), el tipo de lenguaje que nos atañe es el de los lenguajes regulares. Los lenguajes regulares pueden ser descritos usando expresiones regulares, lo que hace que podamos construir nuestro analizador léxico usando nuestra conocida secuencia: Expresión regular NFA DFA Programa El teorema. asegura que podamos representar un lenguaje regular mediante una expresión regular:

23 Teorema.: Un lenguaje es regular si y sólo si alguna expresión regular lo describe. Aunque no demostraremos aquí dicho teorema, podemos apreciar que éste nos permite pasar de una representación a otra con la seguridad de que ambas son equivalentes. El lector interesado en la demostración puede consultar [ref. libro Sipser]. Antes de dar la definición formal de una expresión regular, necesitamos definir las operaciones regulares de las que dicha definición hace uso... Las operaciones regulares La siguiente definición y su respectivo ejemplo los tomamos de [ref. Sipser]. Sean A y B lenguajes. Definimos las operaciones regulares unión, concatenación y estrella (Kleene) como sigue: UNION: A B { x x A x B } CONCATENACIÓN: A B { x y x A y B } * ESTRELLA: A x x x x k 0 y cada x A} { 3 Ejemplo: Sea el alfabeto estándar de 6 letras { a, b, c,, x, y, z }. Si A { good, bad } y B { boy, girl } entonces: A B { good, bad, boy, girl } A B { goodboy, goodgirl, badboy, badgirl } * A {, good, bad, goodgood, goodbad, badgood, badbad, goodgoodbad, goodgoodgood, } Una vez definidas las operaciones regulares, podemos definir una expresión regular. Dicha definición también está tomada de [ref. Sipser]... Definición formal de una expresión regular Decimos que R es una expresión regular si R es:. a para cualquier a ( R R ), donde R y R son expresiones regulares 5. (R R ) 6. ( R * ) donde R es una expresión regular Para el punto, cualquier elemento que pertenezca al alfabeto es una expresión regular. En este caso, la expresión regular a representa el lenguaje a. Para el punto, la expresión regular formada por la cadena vacía (representada por ) representa el lenguaje. Para el punto 3, la expresión regular representa el lenguaje vacío. Es importante aclarar que la expresión regular representa el lenguaje que contiene una sola cadena: la cadena vacía; mientras que la expresión regular representa el lenguaje que no contiene ninguna cadena (incluida la cadena vacía). Se deja como ejercicio al lector diseñar un autómata finito que acepte el lenguaje representado por y el lenguaje representado por respectivamente. Para los puntos 4, 5, y 6, las expresiones regulares representan los lenguajes obtenidos al aplicar las operaciones regulares de unión, concatenación y estrella respectivamente. k i