Autómatas

Títol: Construcción de un compilador con parsing LL(*) y
StringTemplates
Volum: 1/1
Alumne: Alicia González López
Director/Ponent: José Miguel Rivero Almeida

Departament: Lenguajes y Sistemas Informáticos
Data: 23 de Junio del 2011
DADES DEL PROJECTE
Títol del Projecte: Construcción de un compilador con parsing LL(*) y StringTemplates
Nom de l'estudiant: Alicia González López

Titulació: Ingeniería Informática
Crèdits: 37.5
Director/Ponent: José Miguel Rivero Almeida
Departament: Lenguajes y Sistemas Informáticos
MEMBRES DEL TRIBUNAL (nom i signatura)
President: Ramón Ferrer Cancho
Vocal: Pilar Sobrevilla Frisón
Secretari: José Miguel Rivero Almeida
QUALIFICACIÓ
Qualificació numèrica:
Qualificació descriptiva:
Data:
Agradecimientos
Este proyecto ha sido desarrollado en la Facultad de Informática de Barcelona bajo la
supervisión de José Miguel Rivero profesor del departamento de Lenguajes y Sistemas
Informáticos.
En primer lugar quiero agradecer a José Miguel Rivero la oportunidad de desarrollar un

proyecto centrado en el área de Compiladores que más me interesaba. También
agradecer toda su ayuda brindada durante la realización, ya que sin ella no hubiera sido
posible este proyecto.
Me gustaría dar las gracias a mis padres, mi abuelo, a Albert y mis amigos, por la
paciencia que han tenido durante la realización de este proyecto.
Finalmente, a todas aquellas personas que preguntaron sobre qué trataba este proyecto y
tuvieron que aguantar una explicación que les dejó en la misma situación en la que
estaban.
ÍNDICE
1. Introducción ......................................................................................................... - 15 -
1.1. Objetivos del proyecto .................................................................................... - 15 -
1.2. Trabajos Previos ............................................................................................. - 16 -
1.3. Qué es un Compilador .................................................................................... - 17 -
1.3.1. Definición ................................................................................................ - 17 -
1.3.2. Etapas del Compilador ............................................................................. - 18 -
2. Conceptos Teóricos: Etapa de Análisis ............................................................... - 27 -
2.1. Etapa de Análisis ............................................................................................ - 27 -
2.2. Análisis Léxico ............................................................................................... - 28 -
2.2.1. Reconocimiento Léxico ........................................................................... - 29 -
2.2.2. Mecanismos para el reconocimiento ....................................................... - 30 -
2.3. Análisis Sintáctico .......................................................................................... - 35 -
2.3.1. Reconocimiento del Lenguaje ................................................................. - 35 -
2.3.2. Mecanismos para el reconocimiento ....................................................... - 36 -
2.4. Análisis Semántico ......................................................................................... - 46 -
2.4.1. Funcionamiento y Objetivos .................................................................... - 46 -
2.4.2. Sistema de Tipos ...................................................................................... - 47 -
2.4.3. Tabla de Símbolos ................................................................................... - 49 -
2.4.4. Decoración de ASTs ................................................................................ - 49 -
3. Conceptos Teóricos: Etapas de Síntesis .............................................................. - 52 -
3.1. Generación de Código Intermedio .................................................................. - 53 -
3.1.1. Entorno en tiempo de ejecución .............................................................. - 54 -
3.2. Optimización de Código Intermedio .............................................................. - 66 -
3.2.1. Optimización del Código Dividido en Bloques Básicos ......................... - 69 -
3.3. Generación de Código Objeto ........................................................................ - 72 -
3.4. Optimización de Código Objeto ..................................................................... - 73 -
4. Herramientas de Desarrollo de un Compilador ................................................... - 74 -
4.1. ANTLR Parsing .............................................................................................. - 75 -
4.1.1. Estructura de ANTLR .............................................................................. - 75 -
4.1.2. Gramáticas en ANTLR ............................................................................ - 76 -
4.1.3. Principales características ........................................................................ - 78 -
4.1.4. AST Construction .................................................................................... - 92 -
Construcción de un compilador con parsing LL(*) y StringTemplates -7-

ÍNDICE
4.2. ANTLR Tree Parsing ...................................................................................... - 97 -

4.3. StringTemplates ............................................................................................ - 100 -
5. Definición de los Lenguajes Aplicados ............................................................. - 104 -
5.1. Lenguaje CL ................................................................................................. - 105 -
5.1.1. Estructura ............................................................................................... - 105 -
5.1.2. Valores y Tipos ...................................................................................... - 109 -
5.1.3. Expresiones ............................................................................................ - 109 -
5.1.4. Instrucciones .......................................................................................... - 110 -
5.1.5. Aspectos Semánticos del Lenguaje ....................................................... - 111 -
5.2. Z-Code .......................................................................................................... - 114 -
5.2.1. Estructura ............................................................................................... - 115 -
5.2.2. Operandos .............................................................................................. - 116 -
5.2.3. Instrucciones .......................................................................................... - 117 -
6. Trabajo Realizado .............................................................................................. - 120 -
6.1. Trabajo Previo .............................................................................................. - 120 -
6.2. Archivos que intervienen en las diferentes fases .......................................... - 121 -
6.3. Trabajo Realizado ......................................................................................... - 122 -
6.3.1. Etapa Análisis o Front-end .................................................................... - 122 -
6.3.2. Generación de Código Intermedio o Middle-end .................................. - 127 -
6.3.3. Etapa de Síntesis de Generación de Código Ensamblador o Back-end . - 149 -
7. Planificación y Costes del Proyecto .................................................................. - 158 -
7.1. Planificación Inicial del Proyecto ................................................................. - 158 -
7.2. Duración Real del Proyecto .......................................................................... - 161 -
7.3. Desviaciones en la Estimación ..................................................................... - 162 -
7.4. Cálculo de Costes del Proyecto .................................................................... - 162 -
8. Conclusiones y Trabajos Futuros ...................................................................... - 165 -
8.1. Conclusiones ................................................................................................. - 165 -
8.2. Trabajos Futuros ........................................................................................... - 167 -
9. Acrónimos ......................................................................................................... - 169 -
10. Bibliografía ........................................................................................................ - 170 -
Anexo I. Ejemplo del Proceso de Compilación Completo.................................... - 171 -
Anexo II. Subconjunto de Instrucciones de IA-32 ............................................. - 179 -
Construcción de un compilador con parsing LL(*) y StringTemplates -8-

ÍNDICE DE FIGURAS
Figura 1.1 - Etapas de un compilador ......................................................................... - 15 -

Figura 1.2 - Etapas con sus respectivas fases de un compilador ................................ - 18 -
Figura 1.3 - Ejemplo de lenguaje natural ................................................................... - 19 -
Figura 1.4 - Ejemplo de programación ....................................................................... - 19 -
Figura 1.5 - Gramática de lenguaje natural ................................................................ - 20 -
Figura 1.6 - Árbol de las reglas de la Figura 1.3........................................................ - 21 -
Figura 1.7 - Gramática del lenguaje CL ..................................................................... - 21 -
Figura 1.8 - Ejemplo de oración incorrecta semánticamente ..................................... - 22 -
Figura 1.9 - Objetivo de la representación intermedia ............................................... - 23 -
Figura 1.10 - Representación intermedia de la Figura 1.4 ......................................... - 24 -
Figura 1.11 - Traducción en IA-32 de la Figura 1.4 .................................................. - 25 -
Figura 1.12 - Optimización del código de la Figura 1.11 .......................................... - 25 -
Figura 2.1 - Comunicación Lexer – Parser ................................................................ - 28 -
Figura 2.2 - Ejemplo de Análisis Léxico .................................................................... - 29 -
Figura 2.3 - Ejemplo de una máquina de estados ....................................................... - 31 -
Figura 2.4 - Ejemplo DFA .......................................................................................... - 31 -
Figura 2.5 - Ejemplo NDFA ....................................................................................... - 32 -
Figura 2.6 - Ejemplo de expresión regular: Identificador .......................................... - 33 -
Figura 2.7 - Ejemplo de expresión regular: Entero .................................................... - 34 -
Figura 2.8 - Ejemplo de gramática genérica ............................................................... - 36 -
Figura 2.9 - Ejemplo de gramática ............................................................................. - 37 -
Figura 2.10 - Definición de tokens de la gramática .................................................... - 37 -
Figura 2.11 - Programa reconocible por la gramática de la Figura 2.9 ..................... - 38 -
Figura 2.12 - Árbol de derivación .............................................................................. - 39 -
Figura 2.13 - Ejemplo de ambigüedad gramatical ...................................................... - 40 -
Figura 2.14 - Entrada if/then/else ambigua................................................................. - 40 -
Figura 2.15 - Árbol de derivación if/then/else: Opción 1 ........................................... - 40 -
Figura 2.16 - Árbol de derivación if/then/else: Opción 2 ........................................... - 41 -
Figura 2.17 - AST del programa de la Figura 2.11 .................................................... - 42 -
Figura 2.18 - Expresión de una gramática .................................................................. - 43 -
Figura 2.19 - Gramática de ejemplo para Parsing...................................................... - 44 -
Figura 2.20 - Derivación aplicando Parsing LL ........................................................ - 45 -
Figura 2.21 - Derivación aplicando Parsing LR ........................................................ - 45 -
Figura 2.22 - Ejemplo de equivalencia de tipos ......................................................... - 48 -
Figura 2.23 - Programa de ejemplo ............................................................................ - 49 -
Figura 2.24 - AST del programa de la Figura 2.23 .................................................... - 50 -
Figura 2.25 - AST decorado del programa de la Figura 2.23 .................................... - 50 -
Figura 3.1 - Ejemplo de código de tres direcciones ................................................... - 53 -
Figura 3.2 - Estado de la memoria en tiempo de ejecución ........................................ - 56 -
Figura 3.3 - Programa en CL ...................................................................................... - 57 -
Figura 3.4 - Estructura en árbol del programa de la Figura 3.3 ................................. - 57 -
Figura 3.5 - Orden de llamadas en tiempo de ejecución de la Figura 3.3 .................. - 58 -
Construcción de un compilador con parsing LL(*) y StringTemplates - 10 -

ÍNDICE DE FIGURAS
Figura 3.6 - Árbol de activación del programa de la Figura 3.3 ................................ - 58 -

Figura 3.7 - Crecimiento de la pila para el ejemplo de la Figura 3.3......................... - 59 -
Figura 3.8 - Bloque de activación en Z-Code ............................................................. - 60 -
Figura 3.9 - Pila para la secuencia de llamadas de la Figura 3.3 ............................... - 62 -
Figura 3.10 - Cálculo del static_link cuando Dif_niveles = 1 .................................... - 62 -
Figura 3.11 - Cálculo del static_link cuando Dif_niveles = 2 .................................... - 63 -
Figura 3.12 - Cálculo del static_link cuando Dif_niveles > 2 .................................... - 63 -
Figura 3.13 - Copia de una variable de tipo no básico utilizando aux_space ............ - 64 -
Figura 3.14 - Programa con variables de tipo no básico ............................................ - 65 -
Figura 3.15 - Programa de ejemplo para optimizar .................................................... - 67 -
Figura 3.16 - Ejemplo de redundancia en los cálculos ............................................... - 68 -
Figura 3.17 - Ejemplo de redundancia de cálculos ..................................................... - 68 -
Figura 3.18 - Cálculo del acceso a una posición en una tabla .................................... - 69 -
Figura 3.19 - Ejemplo de código intermedio .............................................................. - 70 -
Figura 3.20 - División en bloques básicos del ejemplo de la Figura 3.19 ................. - 70 -
Figura 3.21 - Código de la Figura 3.19 optimizado ................................................... - 71 -
Figura 3.22 - Ejemplo de programación IA-32 .......................................................... - 72 -
Figura 4.1 - Reglas notación BNF .............................................................................. - 76 -
Figura 4.2 - Gramática con notación EBNF ............................................................... - 78 -
Figura 4.3 - Ejemplo de gramática en lenguaje CL .................................................... - 79 -
Figura 4.4 - Gramática de la Figura 4.3 factorizada .................................................. - 79 -
Figura 4.5 - Ejemplo gramática LL(*)........................................................................ - 80 -
Figura 4.6 - Ejemplo gramática LL(*) - Elementos comunes .................................... - 81 -
Figura 4.7 - Factorización de la Figura 4.6 ................................................................ - 81 -
Figura 4.8 - Ejemplo factorización en gramática de CL............................................. - 81 -
Figura 4.9 - Regla gramatical para reconocer una expresión ..................................... - 82 -
Figura 4.10 - Código generado por versiones anteriores de ANTLR para la Figura 4.9 .. -
82 -
Figura 4.11 - Código generado por ANTLR para reconocer la Figura 4.9 ................ - 83 -
Figura 4.12 - DFA para la gramática de la Figura 4.9 ............................................... - 83 -
Figura 4.13 - Regla LL(*)........................................................................................... - 84 -
Figura 4.14 - DFA para la regla de la Figura 4.13 ..................................................... - 84 -
Figura 4.15 - Código de Parsing para la Figura 4.13 ................................................ - 85 -
Figura 4.16 - Ejemplo de gramática ambigua ............................................................ - 86 -
Figura 4.17 - Ejemplo de recursividad izquierda ....................................................... - 86 -
Figura 4.18 - Solución a la recursividad izquierda de la Figura 4.17 ........................ - 86 -
Figura 4.19 - Solución a la recursividad izquierda de la Figura 4.17 usando EBNF - 87 -
Figura 4.20 - Ejemplo de gramática con decisión no LL(*) ....................................... - 87 -
Figura 4.21 - Solución a la decisión no LL(*) de la Figura 4.20 ............................... - 87 -
Figura 4.22 - Ejemplo de regla con predicado semántico .......................................... - 88 -
Figura 4.23 - Gramática que reconoce cadenas de B.................................................. - 89 -
Figura 4.24 - Gramática para reconocer cadenas de hasta cien B’s ........................... - 89 -

ÍNDICE DE FIGURAS
Figura 4.25 - Gramática de ANTLR para reconocer cadenas de hasta cien B’s ........ - 89 -
Figura 4.26 - Regla instr en CL .................................................................................. - 90 -
Figura 4.27 - Fuente de ambigüedad para la gramática de la Figura 4.26 ................. - 91 -
Figura 4.28 - Regla instr con la ambigüedad resuelta ................................................ - 91 -
Figura 4.29 - Predicado sintáctico de la regla de la Figura 4.28 ................................ - 91 -
Figura 4.30 - Ejemplo de aplicación de los operadores de modificación en ANTLR - 93 -
Figura 4.31 - Reescritura de reglas en ANTLR .......................................................... - 94 -
Figura 4.32 - Ejemplo I de reescritura de reglas aplicado a CL ................................. - 94 -
Figura 4.33 - Ejemplo II de reescritura de regla en CL .............................................. - 94 -
Figura 4.34 - Ejemplo de reordenación de elementos en una regla ............................ - 95 -
Figura 4.35 - Ejemplo de raíz de un árbol en CL ....................................................... - 95 -
Figura 4.36 - Ejemplo de creación de nodos imaginarios en CL ............................... - 96 -
Figura 4.37 - Ejemplo de duplicación de árbol en CL ............................................... - 96 -
Figura 4.38 - Ejemplo de recolección de elementos en CL ........................................ - 96 -
Figura 4.39 - Ejemplo expresión a serializar .............................................................. - 98 -
Figura 4.40 - Serialización de la expresión de la Figura 4.40.................................... - 98 -
Figura 4.41 - Ejemplo de gramática para convertir en Tree Grammar ...................... - 98 -
Figura 4.42 - Tree Grammar de la Figura 4.41 .......................................................... - 98 -
Figura 4.43 - Ejemplo de Tree Rule para CL ............................................................. - 99 -
Figura 4.44 - Ejemplo de predicado sintáctico en la Tree Grammar de CL ............ - 100 -
Figura 4.45 - Esquema de un patrón de traducción .................................................. - 101 -
Figura 4.46 - Ejemplo de patrón de la instrucción writeln de CL ............................ - 101 -
Figura 4.47 - Ejemplo de patrón de la llamada a un procedimiento de CL .............. - 102 -
Figura 4.48 - Llamada al patrón de la Figura 4.46 desde el código en CL .............. - 102 -
Figura 4.49 - Llamada al patrón de la Figura 4.47 desde el código en CL .............. - 103 -
Figura 5.1 - Proceso de traducción del código fuente a código objeto ..................... - 104 -
Figura 5.2 - Estructura de un programa en CL ......................................................... - 105 -
Figura 5.3 - Programa en CL: ejemplo sencillo ....................................................... - 106 -
Figura 5.4 - Programa en CL: ejemplo complicado ................................................. - 108 -
Figura 5.5 - Programa en CL: Ejemplo de reglas de visibilidad .............................. - 112 -
Figura 5.6 - Ejemplo de programa CL con procedimientos y funciones anidados .. - 113 -
Figura 5.7 - Estructura de bloques del programa de la Figura 5.6 ........................... - 114 -
Figura 5.8 - Estructura de un programa en Z-Code .................................................. - 115 -
Figura 5.9 - Ejemplo de programa CL...................................................................... - 119 -
Figura 5.10 - Traducción en Z-Code del programa de la Figura 5.9 ....................... - 119 -
Figura 6.1 - Estructura de ficheros del compilador .................................................. - 121 -
Figura 6.2 - Programa en CL con definición de tipo estructurado ........................... - 124 -
Figura 6.3 - Programa en CL con definición de tipos .............................................. - 124 -
Figura 6.4 - Ejemplo de definición circular de tipos ................................................ - 125 -
Figura 6.5 - Programa en CL con punteros .............................................................. - 125 -
Figura 6.6 - Programa en CL con punteros .............................................................. - 126 -
Figura 6.7 - Ejemplo I de programa CL para la generación de Z-Code ................... - 128 -

ÍNDICE DE FIGURAS
Figura 6.8 - Ejemplo II de programa en CL para la generación de Z-Code ............. - 128 -

Figura 6.9 - Ejemplo I de concatenación en la generación de Z-Code ..................... - 130 -
Figura 6.10 - Ejemplo II de concatenación en la generación de Z-Code ................. - 130 -
Figura 6.11 - Generación del Z-Code para constantes ............................................. - 132 -
Figura 6.12 - Generación del Z-Code para operadores unarios ................................ - 132 -
Figura 6.13 - Generación del Z-Code para expresiones binarias ............................. - 133 -
Figura 6.14 - Generación Z-Code para expresiones binarias (II) ............................. - 134 -
Figura 6.15 - Generación del Z-Code para un identificador..................................... - 135 -
Figura 6.16 - Generación del Z-Code para el acceso a un campo de un struct ........ - 136 -
Figura 6.17 - Generación del Z-Code para el acceso a un elemento de una array ... - 137 -
Figura 6.18 - Generación del Z-Code para una llamada a función........................... - 138 -
Figura 6.19 - Generación del Z-Code de acceso al valor apuntado por un puntero . - 139 -
Figura 6.20 - Generación del Z-Code de la dirección de una expresión .................. - 139 -
Figura 6.21 - Generación del Z-Code de la dirección de un identificador ............... - 140 -
Figura 6.22 - Generación del Z-Code de la dirección de un identificador (II) ......... - 141 -
Figura 6.23 - Generación del Z-Code de la dirección del campo de un struct ......... - 141 -
Figura 6.24 - Generación del Z-Code de la dirección de un elemento de un array . - 142 -
Figura 6.25 - Generación en Z-Code de la dirección de elementos apuntados ........ - 142 -
Figura 6.26 - Generación del Z-Code para instrucciones if ...................................... - 143 -
Figura 6.27 - Generación del Z-Code para instrucciones while ............................... - 144 -
Figura 6.28 - Generación del Z-Code para una instrucción de lectura ..................... - 144 -
Figura 6.29 - Generación del Z-Code para una instrucción de escritura .................. - 145 -
Figura 6.30 - Generación del Z-Code para llamadas a procedimiento ..................... - 146 -
Figura 6.31 - Generación del Z-Code para instrucciones de punteros (new y free) . - 146 -
Figura 6.32 - Generación del Z-Code para la instrucción de asignación ................. - 147 -
Figura 6.33 - Generación del Z-Code para calcular el static_link ............................ - 148 -
Figura 6.34 - Generación del Z-Code de recogida de resultados para llamadas a
funciones................................................................................................................... - 148 -
Figura 6.35 - Generación del Z-Code de reserva de espacio para el resultado de
funciones................................................................................................................... - 148 -
Figura 6.36 - Cálculo de la posición en memoria para un temporal ......................... - 153 -
Figura 6.37 - Ejemplo de aplicación de patrones ..................................................... - 153 -
Figura 6.38 - Ejemplo de aplicación de patrones (II) ............................................... - 154 -
Figura 6.39 - Pila en ejecución ................................................................................. - 155 -
Figura 6.40 - Patrón genérico de traducción a IA-32 ............................................... - 157 -
Figura 7.1 - Planificación inicial del proyecto ......................................................... - 160 -
Figura 7.2 - Duración real del proyecto .................................................................... - 161 -
Figura 7.3 - Total horas dedicadas al proyecto ......................................................... - 163 -
Figura 7.4 - Perfiles desarrolladores de las tareas del proyecto ............................... - 163 -
Figura 7.5 - Coste total del proyecto ........................................................................ - 164 -
Figura I.1 - Código del mergesort (I) ....................................................................... - 171 -
Figura I.2 - Código del mergesort (II) ...................................................................... - 172 -

ÍNDICE DE FIGURAS
Figura I.3 - Código del mergesort (III) ..................................................................... - 173 -

Figura I.4 - Código del programa en CL para hacer las pruebas .............................. - 173 -
Figura I.5 - Árbol AST correspondiente al código de la Figura I.4 ......................... - 174 -
Figura I.6 - Árbol AST decorado correspondiente al código de la Figura I.4 ......... - 175 -
Figura I.7 - Z-Code correspondiente al código de la Figura I.4 .............................. - 176 -
Figura I.8 - Representación en IA32 del código de la Figura I.4 (I)........................ - 176 -
Figura I.9 - Representación en IA32 del código de la Figura I.4 (II) ...................... - 177 -
Figura I.10 - Ejemplo de código con error sintáctico ............................................... - 178 -
Figura I.11 - Salida del compilador para un error sintáctico .................................... - 178 -
Figura I.12 - Ejemplo de código con error semántico .............................................. - 178 -
Figura I.13 - Salida del compilador para un error semántico ................................... - 178 -

Capítulo 1. Introducción
1. Introducción
Todo programa desarrollado puede ser directamente ejecutado por un intérprete
o bien, compilado para ser posteriormente ejecutado. En ambos casos existen unas fases
de análisis que detectan la corrección del programa. Un compilador, que no es más que
otro programa, después de verificar la corrección, continúa y finaliza la traducción a
código objeto.
A modo de introducción, diremos que un compilador es un programa formado por las

siguientes etapas:
Figura 1.1 - Etapas de un compilador
Donde las etapas se ejecutan de forma secuencial y cada una tiene como entrada la
salida de la etapa que le precede, que no son más que diversas representaciones internas
del código fuente inicial.
El objeto de estudio de este proyecto ha sido la implementación de un compilador

enfocándose principalmente en las etapas de síntesis, es decir, en el Middle-end y el
Back-end utilizando para ello nuevas herramientas que permiten construir algunas fases
del compilador de forma semiautomática.
1.1. Objetivos del proyecto

El principal objetivo del proyecto ha sido construir un mejor compilador de CL.
El término “mejor” se refiere a que el nuevo compilador acepte un lenguaje más
potente, sea más eficiente y el código de la representación intermedia sea más legible,
facilitando además la posibilidad de incorporar optimizaciones.
Para conseguir el propósito final, se han marcado otros objetivos a alcanzar. A

continuación se plantearán éstos en función de la etapa del compilador a la que
corresponden.

 Etapa de análisis o Front-end
o Ampliación del lenguaje CL, permitiendo el uso de memoria dinámica y

de tipos definidos por el usuario. Para ello ha sido necesario desarrollar
las fases de Análisis Léxico, Sintáctico y Semántico.
 Etapa de síntesis del código intermedio o Middle-end
o Definición del código intermedio Z-Code, una nueva representación

intermedia en forma de código de tres direcciones definido
específicamente para este proyecto. Esta representación debe cumplir
además con las siguientes características:
- Aportar legibilidad y facilidad de interpretación.
- Mayor eficiencia espacial y temporal del código generado.
- Facilitar el trabajo de optimización.
o Generación del código intermedio Z-Code.
 Etapa de síntesis del código objeto o Back-end
o Generación de código ensamblador IA-32.
Otro objetivo aplicado al desarrollo de todas las etapas del compilador ha sido la
utilización de la herramienta ANTLR v3 y la aplicación de los nuevos mecanismos que
incorpora para automatizar el desarrollo de muchas fases del compilador.
Así pues, el resultado final del proyecto es un compilador para el lenguaje CL, que ha
sido implementado con los últimos avances que proporcionan las herramientas actuales
de desarrollo, y que además, cumple con los objetivos que se han fijado anteriormente.
1.2. Trabajos Previos

Ya existían compiladores para el lenguaje CL, puesto que en la asignatura de
Compiladores de esta facultad existe una práctica que consiste en implementar las
primeras etapas del compilador.
A pesar de que existen compiladores para CL, ninguno cumplía con las características
deseadas, es por ello que se procedió a la realización de este proyecto.

La implementación del compilador no parte desde cero puesto que ya se había trabajado
antes en él y, por lo tanto, había partes implementadas. Es por ello, que el proyecto se
ha enfocado principalmente en dos de las tres etapas en las que se divide el compilador.
Es importante destacar que, aunque se parte de un trabajo previo, parte de ese trabajo se
ha visto modificado, debido a ampliaciones realizadas y al uso de las nuevas
herramientas de desarrollo. Concretamente, la etapa de Análisis o Front-end es la que
estaba más desarrollada.
1.3. Qué es un Compilador

A continuación, se introducirá muy brevemente qué es un compilador y cuáles son
las funciones de cada una de las etapas que componen su estructura.
1.3.1. Definición
Un compilador es un programa que traduce un código fuente en un lenguaje de
alto nivel a otro lenguaje de programación de más bajo nivel, el código objeto, que
puede ser directamente ejecutable. Para realizar la traducción, primero se debe
comprobar la corrección del código fuente informando de posibles errores al usuario. El
proceso de compilación se divide en diferentes etapas llevándose a cabo en cada una de
ellas una tarea diferente.
Como hemos visto en la Figura 1.1 - Etapas de un compilador, las principales etapas
son tres:
 Front-end.
 Middle-end.
 Back-end.
Hay que destacar el hecho que no hay un acuerdo total en la forma de dividir el trabajo
el compilador. En la principal bibliografía consultada [1], tan sólo se reconocen las
etapas Front-end y Back-end. Pero, cada vez más se reconoce una nueva etapa
intermedia, debido a la importancia que ésta está tomando hoy día el uso de una
representación intermedia.
También podemos encontrar diferencias relacionadas con las tareas que realiza cada una
de las etapas debido a que no siempre la estructura formal de las etapas del compilador
se corresponde con la estructura real de muchas implementaciones.

1.3.2. Etapas del Compilador

Funcionalmente, la compilación es un proceso lineal que se divide en diferentes
etapas que se muestran en el siguiente gráfico en el orden que se realizan. Cada etapa se
estructura en diferentes fases que realizan cada una de las tareas correspondientes. A
continuación se muestra una figura donde aparece la estructura típica de un compilador
con sus tres etapas y sus correspondientes fases.
Figura 1.2 - Etapas con sus respectivas fases de un compilador

En realidad, comprender el trabajo que realiza un compilador en sus primeras etapas es

muy fácil si se hace una analogía con el lenguaje natural y cómo éste se forma de
manera correcta y comprensible. Así pues, para explicar algunas de las fases, se
realizará la correspondiente analogía entre un lenguaje de programación y el lenguaje
natural, ya que para el caso de este último, cuando tenemos una oración y analizamos su
corrección, implícitamente estamos realizando los mismos pasos que, hasta cierto nivel,
se realizan en la primera etapa de un compilador.
Las tareas con las que cuenta el compilador están divididas en tres grandes etapas: las
de análisis o también llamadas de Front-end , las que tratan con la representación
intermedia (RI) del lenguaje a compilar, agrupadas en el Middle-end y finalmente, las
de síntesis del código objeto, también conocidas como Back-end.
Antes de empezar con la definición de cada una de las etapas, se plantean dos ejemplos,
uno para el caso del lenguaje natural y otro para nuestro ejemplo de programación en
lenguaje CL.
A lo largo de la explicación, se hará referencia a estos dos ejemplos, mostrando cuál es

la analogía entre ambos casos para cada una de las etapas comentadas.
program
vars
a int
La casa de mi abuela es muy endvars
grande a := 3
write(a + 1)
endprogram
Figura 1.3 - Ejemplo de lenguaje natural Figura 1.4 - Ejemplo de programación
Dentro de la etapa de Análisis encontramos, según el orden en el que se realizan, las

siguientes fases:
 Análisis Léxico o Scanning. Durante esta fase se lee el código fuente y se

fragmenta en tokens o componentes léxicos. Cada uno de estos tokens estará
formado por una secuencia de caracteres, que es la unidad mínima de nuestro
lenguaje. Los tokens se definen a partir el alfabeto del lenguaje fuente a tratar, y
cada uno de ellos, tiene un significado propio.
A medida que se fragmenta la entrada, también se comprueba la corrección de

los caracteres de entrada, es decir, que si una sucesión de esos caracteres no
coincide con alguno de los patrones definidos (tokens), se habrá encontrado un
error léxico.

Después de esta fase, el resultado para ambos ejemplos sería el siguiente:
o Para el caso del lenguaje natural, se obtendría el siguiente listado de

tokens: DETERMINANTE, NOMBRE, PREPOSICIÓN, DETERMINANTE,
NOMBRE, VERBO, ADVERBIO, ADJETIVO, SIGNO_PUNTUACION.
o Para el caso de nuestro lenguaje de alto nivel CL deberíamos obtener el

siguiente listado de tokens: PROGRAM, VARS, ID, INT, ENDVARS,
ID, ASIG, INT_CONST, WRITE, ABREPAR, ID, PLUS, INT_CONST,
CIERRAPAR, ENDPROGRAM.
Un posible error en este punto, se podría deber a que hay un conjunto de

caracteres de la entrada que no se corresponde con ninguna de las
expresiones regulares que definen los tokens del lenguaje. Un posible
ejemplo de eso sería el caso en que en nuestro programa, en lugar de
escribir “:=” hemos escrito “::” y por lo tanto, se produce un error
léxico.
 Análisis Sintáctico o Parsing. En este punto comprobamos si la secuencia de

tokens obtenida de la fase anterior es aceptada por la gramática del lenguaje que
estamos tratando, agrupando los tokens en frases gramaticales. Si es así, el
programa fuente será sintáctica o estructuralmente correcto. La gramática del
lenguaje se define mediante reglas recursivas. Nuestro resultado ahora será una
jerarquía de tokens, representados en forma de árbol.
o Para el ejemplo del lenguaje natural, los tokens reconocidos ahora deben
estar agrupados dentro de una oración que cumpla las siguientes reglas:
oracion: sujeto predicado PUNTO

sujeto: (nombre | pronombre | determinante nombre)
(nombre | compl_nominal)
predicado: VERBO compl_predicado
....
Figura 1.5 - Gramática de lenguaje natural
De esta manera, acabamos comprobando que la frase inicial con la que

contábamos consta de un sujeto, un predicado y un punto final.
A continuación se muestra el árbol para el ejemplo del lenguaje natural:

Figura 1.6 - Árbol de las reglas de la Figura 1.3
Ahora veamos qué pasa con el ejemplo del lenguaje de programación.

Supongamos que en la gramática de CL se ha definido las instrucciones
del ejemplo como:
instr: ID ASIG expr | WRITE ABREPAR expr CIERRAPAR

expr: expr_simple (PLUS expr_simple) *
expr_simple : ID | INT_CONST
Figura 1.7 - Gramática del lenguaje CL
Si tuviéramos una entrada de la forma write(a 1), no se podría

reconocer por nuestra gramática, ya que después de la a se espera o bien
el token PLUS o el token CIERRAPAR. En este caso, el compilador emitiría
un error sintáctico al encontrarse en ese punto, localizándolo y
explicando a qué se debe.
Cabe destacar que conceptualmente, entendemos las fases de Análisis

Léxico y Sintáctico como dos fases diferenciadas, pero en el momento de

la ejecución, el compilador puede realizar estas dos etapas de forma

conjunta. En este caso el analizador sintáctico solicita nuevos tokens al
analizador léxico a medida que los va necesitando.
 Análisis Semántico. Llegados a este punto nos interesa comprobar que además
que lo que teníamos inicialmente en la entrada esté bien escrito y estructurado,
tenga también un sentido.
Con el ejemplo planteado del lenguaje natural, podemos comprobar que la

oración tiene un sentido pero, si no se realizaran en esta etapa algunas
comprobaciones, podríamos encontrar oraciones como la siguiente:
El casa de mi abuela vuela normalmente.
Figura 1.8 - Ejemplo de oración incorrecta semánticamente
Según las reglas gramaticales del idioma castellano, la oración anterior es

correcta, ya que consta de las partes necesarias: sujeto, predicado y punto. Sin
embargo, ¿qué pasa con su significado? Lógicamente, una casa no vuela y por lo
tanto, esta oración realmente no tiene un significado correcto para los parlantes
de la lengua. Pero además, esta oración presenta otro problema que es la
concordancia de género entre el determinante y el nombre del sujeto.
Para el caso de los lenguajes de programación esto es mucho más sencillo.

Analizar si es correcto el código o no, básicamente se refiere a realizar
comprobaciones como que el tipo pertinente para cada una de las operaciones
sea correcto, que los identificadores usados estén declarados, que las llamadas a
funciones o procedimientos sean correctos,... y en general, comprobaciones que
dependen del lenguaje a analizar. En el ejemplo de CL definido al principio,
aparece la instrucción: write(a+1).
Si en lugar de write(a+1) tuviéramos la instrucción write(a+b), donde b

hubiera sido una variable declarada de tipo booleano, el compilador emitiría un
error semántico. Éste se debe a que a es de tipo entero y dado que CL no permite
la coerción de tipo booleano a entero, no se puede realizar la operación de suma.
 Generación de Código Intermedio ó Representación Intermedia. Antes de

todo, es importante entender la importancia de que los compiladores utilicen
una representación intermedia del código fuente antes de traducir al lenguaje
objeto final. Como bien hemos explicado en este capítulo, un compilador acaba
siendo, entre otras cosas, un traductor de un lenguaje de alto nivel a uno de más
bajo nivel. Así pues, para diferentes lenguajes de alto nivel y diferentes
arquitecturas tendremos que realizar diferentes traducciones y por tanto,

implementar diferentes compiladores. Para facilitar el desarrollo de una familia

de compiladores es habitual definir una representación intermedia del código y
una estructura de compilador como la que se muestra a continuación.
Figura 1.9 - Objetivo de la representación intermedia
En las etapas de Front-end y Middle-end, el código fuente se analiza y se traduce

a código intermedio, dando como resultado un código independiente de la
arquitectura y del lenguaje original.
En el Back-end se realiza la traducción del código intermedio al código objeto

específico la plataforma donde se va a ejecutar.
Entonces, se debe entender que lo que el compilador realiza en esta fase es la

traducción a un código intermedio para una cierta máquina abstracta. Los
principales objetivos son que la representación intermedia sea fácil de generar y,
además, que sea fácil de traducir al código objeto. Es por ello que suele ser una
representación de compromiso entre una representación muy abstracta tipo
código en forma de árbol y una representación demasiado concreta en forma de
lenguaje ensamblador.
Usualmente, esta representación intermedia acaba siendo un pseudocódigo de

tres direcciones, siendo el código una secuencia de instrucciones donde cada una
tiene un máximo de tres operandos.
Volviendo al ejemplo del inicio de este apartado (Figura 1.4), el código en

representación intermedia generado es el siguiente:

program:
; parameters
; static_link
; endparameters
;
; variables
; a 4
; endvariables
a := 3
t0 := a + 1
wrii t0
stop
Figura 1.10 - Representación intermedia de la Figura 1.4
 Optimización del Código Intermedio. Cualquier proceso de optimización lo

que pretende es conseguir resultados más eficientes. En el caso de los
compiladores, contamos con dos tipos de optimizaciones, las que son
dependientes de la arquitectura y las que no. En esta fase, llevaremos a cabo las
operaciones de optimización no dependientes de la arquitectura. El tiempo de
respuesta de un compilador depende en gran parte del número y la complejidad
de las optimizaciones que se realizan en esta fase.
Existen dos tipos de optimizaciones, las que se refieren a la eficiencia temporal y
las de la espacial, aunque en el ámbito de los compiladores normalmente se hace
mayor hincapié en las optimizaciones de tiempo.
Es importante destacar el hecho que con la optimización de código intermedio
no se busca un código óptimo puesto que no se puede calcular en todos los casos
al tratarse de un problema indecidible.
En general, las optimizaciones independientes de la arquitectura se dedican a
analizar la representación intermedia en búsqueda de instrucciones y/o cálculos
redundantes, el uso de instrucciones que no implican ningún cambio en el
resultado y que por tanto se pueden eliminar; y, en general, todo aquello que
pueda hacer perder tiempo durante la ejecución del código sin afectar al
significado del programa.
Si nos fijamos en el código intermedio de la Figura 1.10, realmente el conjunto
de instrucciones se puede reducir a realizar un wrii 4 seguido de la instrucción
stop. Esto es posible debido a que en ningún otro punto del programa se hace
uso de la variable a y por lo tanto, no es necesario ni siquiera declarar tal
variable.

 Generación Código Objeto. En esta fase se realiza la traducción del código

intermedio al código objeto concreto de la arquitectura en la que vamos a
ejecutar el programa
A la hora de generar el código objeto es importante hacer un buen uso de los
registros disponibles en la arquitectura, los modos de direccionamiento
adecuados y traducir usando las instrucciones o conjuntos de instrucciones más
apropiados.
Es importante que a la hora de traducir una instrucción en representación
intermedia a código objeto se realice de una forma bastante óptima a pesar de
que tampoco se trata de generar el código óptimo, ya que para ello el compilador
consta de la siguiente fase.
El código ensamblador generado para el ejemplo de la Figura 1.4, es el que se
muestra en la figura siguiente:
movl $3, -4(%ebp)

movl -4(%ebp), %eax
movl $1, %edx
addl %eax, %edx
movl %edx, %ebx
pushl %ebx
Figura 1.11 - Traducción en IA-32 de la Figura 1.4
 Optimización del Código Objeto. Finalmente, realizamos las optimizaciones

dependientes de la arquitectura, que serán posibles después de haber estudiado
en detalle el funcionamiento de ella. El resultado de esta etapa es pues el código
objeto optimizado que ya puede ser directamente ejecutado.
Siguiendo con el ejemplo que hemos visto a lo largo de este capítulo, la
optimización del código ensamblador generado podría quedar de la siguiente
manera:
movl $3,-4(%ebp)
movl $3, %eax
addl $1, %eax
pushl %eax
Figura 1.12 - Optimización del código de la Figura 1.11
Para optimizar, se ha evitado operar con memoria y hacer uso de un menor

número de registros para realizar los cálculos.

En posteriores capítulos se tratarán en detalle aquellas etapas y las correspondientes

fases en las que se ha centrado este proyecto.

Capítulo 2. Conceptos Teóricos: Etapa de Análisis
2. Conceptos Teóricos: Etapa de Análisis

En este capítulo se profundizará en algunos aspectos de la estructura interna del
compilador y de cómo éste funciona en la etapa de análisis, permitiendo entender en
posteriores apartados las herramientas utilizadas para el desarrollo de este compilador.
Se hará especial hincapié en aquellos aspectos más importantes para futuras

explicaciones, pero algunos conceptos muy básicos de teoría de la computación se darán
por conocidos.
2.1. Etapa de Análisis

Si nos planteamos las bases del castellano o cualquier lenguaje natural, podemos
observar que los textos se componen de oraciones. A su vez, las oraciones se componen
de palabras y, finalmente, las palabras de caracteres. Lo que las personas
inconscientemente hacemos ante un texto, es leer los caracteres e irlos agrupando en
palabras reconocibles, que a su vez forman oraciones.
Además, a medida que reconocemos el lenguaje realizamos diferentes comprobaciones

sobre la corrección léxica, sintáctica y semántica del mismo, como la existencia de
faltas de ortografía y la concordancia de género y número.
Así pues, nuestro cerebro desglosa la función de reconocimiento y corrección del

lenguaje en las siguientes tareas:
 Reconocimiento a nivel de vocabulario.
 Reconocimiento a nivel gramatical.
 Verificación de la corrección semántica del texto.
En el ámbito de los compiladores ocurre lo mismo que lo que hemos comentado con el
lenguaje natural, pero refiriéndonos a ello con diferentes términos y por supuesto,
siguiendo un orden más lineal. El reconocimiento a nivel léxico se realiza en lo que
conocemos como Scanner o Lexer, y el reconocimiento de la gramática del lenguaje se
realiza en el Parser. El Scanner obtiene componentes léxicos (tokens) a partir de los
caracteres de entrada y pasa esa secuencia de tokens como entrada al Parser. La
diferencia entre ambos radica en que el Lexer reconoce palabras a partir de una cadena
de caracteres, mientras que el Parser reconoce estructuras gramaticales a partir de una
cadena de palabras (tokens).

Cabe mencionar el hecho que a pesar de que a nivel conceptual entendamos esta tarea
como dos reconocedores independientes, habitualmente a nivel de implementación,
Scanner y Parser trabajan de manera conjunta, siendo el Lexer quien, bajo demanda, lee
un nuevo token y lo pasa al Parser.
Figura 2.1 - Comunicación Lexer – Parser
La decisión de dividir esta primera tarea de análisis en dos fases, Lexer y Parser se
fundamenta en [2]:
 Mayor facilidad en el diseño de los algoritmos respectivos.
 Mayor eficiencia en el compilador. La división en dos fases permite ajustar la

potencia de los algoritmos utilizados a la necesaria para realizar cada una de las
tareas.
 Mayor portabilidad. Los cambios realizados en una de las fases, no afectan a la

otra. Por ejemplo, si deseamos ampliar o modificar el conjunto de componentes
léxicos que se pueden reconocer, realizaremos cambios que sólo afectarán al
Lexer.
Una vez completadas las tareas del Lexer y Parser, se pasaría a realizar la
comprobación de la corrección semántica del código. Este proceso recibe el nombre de
Análisis Semántico o Type Checking.
Durante el Análisis Semántico, se comprueba que la entrada cumple otro tipo de

propiedades no estructurales del lenguaje que tienen que ver con el significado de la
entrada. En el caso de los lenguajes de programación, se trata básicamente de la
comprobación de tipos.
2.2. Análisis Léxico

En los siguientes apartados, se explicarán en detalle el funcionamiento y los
mecanismos formales con los que trabaja el compilador durante el Análisis Léxico.

2.2.1. Reconocimiento Léxico

El reconocimiento a nivel léxico consiste en ir leyendo la secuencia de
caracteres, que forman el código de entrada, y obtener una partición de ésta en una la
lista de componentes léxicos. La mayoría de estos componentes son relevantes para
posteriores etapas del compilador. Otros como los separadores, en cambio no lo son y
serán omitidos y eliminados para posteriores etapas.
Se puede decir que uno de los objetivos del Análisis Léxico es simplificar el trabajo del
Parser.
El Lexer recibe como entrada una cadena de símbolos que es todo el programa.
Volviendo al símil con el lenguaje natural, es como si recibiera una secuencia de
caracteres muy larga, que se compone de otras palabras, espacios, signos de
puntuación... Por lo tanto, su función es intentar encontrar dentro de esa secuencia de
caracteres, palabras más pequeñas pertenecientes a nuestro lenguaje, que permitan partir
la entrada en algo más sencillo de interpretar y corregir.
Para clarificar este proceso, veamos un ejemplo aplicado a los lenguajes de

programación. La Figura 2.2 muestra un ejemplo de programa en lenguaje CL, el cual
vamos a utilizar para los ejemplos y para el que se ha construido el compilador.
program
vars
a int
b int
c bool
endvars
a := 1
b := 2
a := a + b
if a = 3 then
write(“Correcto”)
else
write(“Incorrecto”)
endif
endprogram
Figura 2.2 - Ejemplo de Análisis Léxico
Para empezar, debemos comprender que cuando hablamos de lenguajes de

programación, los tipos de componentes léxicos que podemos encontrar son: palabras
clave, identificadores, símbolos de asignación, números, operadores...

Por lo tanto, en el ejemplo de la Figura 2.2, entenderíamos ese texto de entrada al que
nos referimos como la siguiente secuencia de caracteres:
program vars a int b int c bool endvars a := 1...
Así pues, lo que haría el Lexer sería empezar a leer la palabra “program”, más en
concreto, el carácter “p” y seguiría con las siguientes letras. Al llegar a la “m” de
“program”, como se daría cuenta que existe una palabra clave de nuestro lenguaje que
es program, guardaría esa información como relevante. Después, empezaría con el
reconocimiento de la palabra “vars”, símbolo a símbolo, de igual manera que para
“program”. Así sucesivamente analizaría toda la entrada hasta finalizar con la palabra
clave endprogram.
Acto seguido, reconocería que existe un salto de línea, pero esta información será
omitida para la siguiente fase. Algunos componentes léxicos como separadores,
espacios, comentarios....también serán omitidos.
Por lo tanto, llegados a este punto, el Lexer habría seleccionado como los siguientes
tokens:
PROGRAM, VARS, IDENTIFICADOR (a), INT, IDENTIFICADOR (b), INT,
IDENTIFICADOR(c), BOOL, ENDVARS, IDENTIFICADOR (a), :=, ENTERO(1),
IDENTIFICADOR(b), :=, ENTERO(2), IDENTIFICADOR(a), IDENTIFICADOR(a),
+, IDENTIFICADOR(b), IF, IDENTIFICADOR(a), =, ENTERO(3), THEN, WRIS,
STRING(Correcto), ELSE, WRIS, STRING(Inconrrecto), ENDIF, ENDPROGRAM
Como podemos observar, cuando hablamos de las variables, nos referimos a ellas como
identificadores y es que, para el compilador, a estas alturas del análisis, simplemente es
un componente léxico del lenguaje que reconoce como identificador sin importarle qué
nombre recibe. Lo mismo pasa con los strings y con los números, simplemente son
componentes léxicos que pertenecen al lenguaje correspondiente independientemente
del texto asociado. Cabe destacar el hecho que, aunque a nivel de la etapa de análisis es
indiferente el valor de los componentes léxicos, es necesario guardar esta información
puesto que más adelante se hará uso de ella.
A efectos prácticos, al final de esta etapa, lo que tenemos como resultado es que hemos
partido el código fuente y de ahí, hemos extraído un conjunto de componentes léxicos.
2.2.2. Mecanismos para el reconocimiento

Para llevar a cabo el Análisis Léxico, el compilador hace uso de diferentes
herramientas formales que detallaremos en este apartado. Además, introduciremos
conceptos clave necesarios para comprender en detalle este y posteriores capítulos.

2.2.2.1. Autómatas Finitos
El lenguaje que define cada componente léxico será un lenguaje regular, por lo
tanto vamos a utilizar máquinas de estados (autómatas finitos) y algoritmos de
reconocimiento de expresiones regulares para realizar el Análisis Léxico.
Las máquinas de estado son un modelo de comportamiento de un sistema con entradas y

salidas, en donde las salidas dependen no sólo de las entradas actuales, sino también de
las anteriores. Una máquina de estados se compone de estados y transiciones y trabaja
siempre sobre un alfabeto concreto. Las transiciones nos indican las conexiones entre
los estados y por tanto, qué entrada hemos de recibir para poder pasar al siguiente
estado.
Representaremos las máquinas de estado mediante diagramas de estados como el del

siguiente ejemplo.
Supongamos la palabra del lenguaje: bool. La figura inferior muestra una máquina de
estados para el reconocimiento de esta palabra.
Figura 2.3 - Ejemplo de una máquina de estados
El estado E0 es el estado inicial de la máquina y el E5 es el estado final o de aceptación,

el cual indica que hemos llegado a una palabra correcta dentro de nuestro lenguaje.
Existen dos tipos de autómatas finitos a considerar:
 DFA (Deterministic Finite Automaton). Los DFA se caracterizan porque el

número de transiciones de un estado a otro con un mismo símbolo del alfabeto
es como máximo una y no tienen λ-transiciones.
Figura 2.4 - Ejemplo DFA

Este DFA reconoce las palabras de la forma: ab a, para el alfabeto ∑ =

{a,b}.
Como podemos observar, no existen dos posibles transiciones para un mismo

símbolo desde un mismo estado. Como ya se ha explicado antes, E0 es el estado
inicial y E5 el estado final.
 NDFA (Nondeterministic Finite Automaton). La diferencia con los DFA

reside en el hecho que para cada símbolo de entrada en un estado puede haber
más de una transición y además, pueden haber λ-transiciones. Cabe destacar el
hecho que todo NDFA tiene un DFA equivalente encontrado aplicando un
algoritmo de determinización.
Figura 2.5 - Ejemplo NDFA
El NDFA del ejemplo reconoce las palabras del tipo: a b del alfabeto ∑ =
{a,b}. En este caso sí que podemos observar que en el estado E2 existen dos
transiciones para el mismo símbolo de entrada a. Esta es una de las diferencias
que hemos comentado que existe con los DFA.
El estado E0 y el estado E5 representan lo mismo que para los DFA.
En el Análisis Léxico de un compilador, se usan los NDFA y DFA para el

reconocimiento de los componentes léxicos del lenguaje de igual manera que lo
podríamos hacer con el lenguaje natural para reconocer palabras y signos de puntuación.
2.2.2.2. Token
Los componentes léxicos que reconocen los DFA o NDFA y por tanto, palabras
que son importantes para nuestro análisis, reciben el nombre de token.
Cuando hablamos de lenguajes de programación habituales, el Lexer busca reconocer

los siguientes tipos de tokens:

 Palabras clave propias del lenguaje: program, vars, endvars, if,

while,...
 Operadores: +, <, =, :=, AND,OR, ...
 Identificadores: x, y, oldValue,...
 Valores enteros: 520, 152, 1,...
 Cadenas de caracteres: “Hello World”,...
 Otros símbolos propios del lenguaje: paréntesis, corchetes, puntos y comas,

comas,..
También reconocerá otros componentes léxicos como los separadores y comentarios,

aunque éstos no pasarán a posteriores etapas del compilador, dado que no representan
información relevante en el proceso de compilación.
Habitualmente encontramos dos formas de definir un token en función de su naturaleza:
 Palabra formada por una secuencia fija de caracteres. Por ejemplo, las palabras
clave del lenguaje: program, vars, while, endwhile,...
 Palabras formadas por secuencias de símbolos variables, como es el caso de los

identificadores, enteros, strings..., pero que también deben especificarse
mediante expresiones regulares.
2.2.2.3. Expresiones Regulares
Una expresión regular nos permite definir el conjunto de palabras que forman
parte de un lenguaje regular. Por ejemplo, podemos usar expresiones regulares para la
definición de los identificadores. Generalmente el programador puede proporcionar
cualquier nombre para identificar una variable, función, procedimiento,....siempre que
éste comience con un carácter alfabético que puede ir seguido de cualquier número de
caracteres alfanuméricos. Por ello, definimos los identificadores mediante una expresión
regular como la siguiente:
IDENTIFICADOR : [A-Za-z][a-zA-Z0-9]*
Figura 2.6 - Ejemplo de expresión regular: Identificador
Entre los primeros corchetes de la definición de la Figura 2.6, especificamos el

conjunto de caracteres al que pertenece el primer símbolo del identificador. El asterisco

aplicado a la expresión regular que le precede indica que el segundo y posteriores

caracteres alfanuméricos pueden aparecer cero o más veces.
Otro de los tokens que deberíamos definir como una expresión regular son los enteros,
los cuáles podríamos definir como:
ENTERO : [1-9][0-9]* | 0
Figura 2.7 - Ejemplo de expresión regular: Entero
Con la definición de la figura Figura 2.7, se indica que un entero será un cero o bien un
número indeterminado de cifras donde la primera cifra no es un cero (puesto que no se
permite que un número entero empiece por cero) seguido de cualquier otro número de
cifras.
Cada uno de los componentes léxicos será definido mediante una expresión regular,
aunque en ocasiones el lenguaje regular correspondiente a algunos de ellos incluye una
sola palabra como por ejemplo, las palabras clave del lenguaje.
Habitualmente, en el contexto de los compiladores se trabaja con DFAs construidos a

partir de NDFAs. Los NDFAs, a su vez, se construyen a partir de las expresiones
regulares mediantes las que se definen los componentes léxicos.
Una buena forma de implementar un analizador léxico sería construir el diagrama que
representa la estructura de los tokens del lenguaje que estamos tratando y luego traducir
esto en un algoritmo para reconocer tokens, aunque como se puede imaginar y,
adelantándonos a lo que veremos en próximos capítulos, no es la forma más sencilla de
hacerlo, puesto que existen hoy en día herramientas automáticas que generan estos
algoritmos.
Los analizadores léxicos se fundamentan en un algoritmo que se encarga de reconocer

el prefijo más largo de una determinada entrada. Para ello, el algoritmo comprueba
mediante los DFAs correspondientes a todas las expresiones regulares que definen los
tokens, cuáles reconocen el prefijo leído hasta el momento. En el caso que alguno de
ellos reconozca un cierto prefijo, toma nota de ello, pero si existe algún otro DFA que
continua reconociendo un prefijo aún mayor, se quedará con este último token como
resultado, ya que es el que representa un prefijo más largo.
A la hora de implementar el Análisis Léxico deberemos tener cuidado con la definición

de tokens y el orden en el que ésta se realiza. Como ya se ha comentado, el algoritmo
del analizador léxico buscará siempre reconocer el prefijo más largo de una determinada
entrada por lo que a la hora de implementarlo, deberemos tener en cuenta el siguiente
caso:

 La definición de los tokens correspondientes a las palabras claves debe ser

previa (debe tener prioridad) a la definición del token identificador. Imaginemos
el caso de la palabra clave while. Si tuviéramos primero la definición del token
IDENTIFICADOR, nunca llegaríamos a reconocer el token WHILE, puesto que
“while” también podría ser reconocido por la expresión regular que define los
identificadores.
Así pues, una vez reconocido el prefijo más largo, en caso de empate, el algoritmo del
analizador léxico tomará como token reconocido el que se ha definido en primer lugar
en la lista de tokens.
2.3. Análisis Sintáctico

Durante el Análisis Sintáctico se comprueba la corrección de la estructura del
código. Así como en el Análisis Léxico se obtiene la secuencia de tokens que aparecen
en la entrada, el analizador sintáctico verifica que ésta forma un programa
estructuralmente correcto tal como especifica la gramática del lenguaje.
2.3.1. Reconocimiento del Lenguaje

El reconocimiento del lenguaje es parecido en algunos aspectos al del léxico. La
principal diferencia reside en el hecho que necesitaremos poder expresar recursividad
para describir nuestro lenguaje y en general, todos los lenguajes de programación. Por
ello, ya podemos observar que las expresiones regulares no nos serán útiles y es por eso
que necesitaremos nuevos mecanismos expresivos más potentes aún no explicados
como las gramáticas.
El objetivo de esta etapa es comprobar que dada una secuencia de tokens pasada desde
el Lexer, éstos forman un programa correcto escrito en un determinado lenguaje,
notificando los posibles errores al usuario. Es decir, actúa como un filtro previo en el
análisis de la corrección del programa facilitando el trabajo de la próxima etapa
(Análisis Semántico).
En esta etapa también nos encargaremos de eliminar información no relevante para las
posteriores etapas como por ejemplo, los paréntesis ahora sobrantes.
En cuanto a la actuación del Parser, cuando éste encuentra un error lo reporta al usuario
indicando el motivo y la localización. Normalmente, el propio compilador se encarga de
recuperarse del error y continuar con fase de Análisis Semántico, aunque esta opción no
es fácil de implementar y a veces puede llevar a detectar más errores.

La herramienta usada para el desarrollo del compilador de CL (ANTLR v3), dispone de

una opción de recuperación de errores que se puede habilitar, pero que no se ha usado.
Por tanto el compilador de CL desarrollado en este proyecto, no cuenta con la
recuperación de errores, de forma que si encuentra un error durante la fase de Análisis
Sintáctico, éste informa al usuario del error y termina su ejecución.
2.3.2. Mecanismos para el reconocimiento

Como resultado del Análisis Sintáctico obtendremos un árbol de sintaxis
correspondiente al análisis gramatical de esa entrada. Posteriormente, este árbol pasa a
ser la nueva representación interna del programa inicial.
Así pues, en este apartado, las principales herramientas formales con las que
trabajaremos son las gramáticas, los árboles de derivación (Parse Tree) y los árboles de
sintaxis abstracta (Abtract Syntax Tree en inglés), a los que nos referiremos como AST
de aquí en adelante.
También, veremos cuáles son los algoritmos de reconocimiento con los que trabaja esta
etapa del compilador y la información que necesitan.
2.3.2.1. Gramáticas
Como hemos introducido anteriormente, las gramáticas son la herramienta que

usaremos para describir formalmente nuestro lenguaje y que por tanto, usará el Parser
para reconocerlo.
El Parser trabaja a partir de una definición del lenguaje hecha mediante una gramática
contextual (CFG).
Una gramática está formada por un conjunto de reglas de la forma [2]:
A: α1| α2 | … | αn
Figura 2.8 - Ejemplo de gramática genérica
Donde αi puede ser una cadena de símbolos terminales o no.
Hay que destacar el hecho que para la definición de las reglas se usa la notación EBNF
(Extended Backus–Naur Form). Este tipo de notación no aporta un mayor poder
expresivo a la gramática, pero sí permite escribirla de manera más compacta y

entendible, ya que ésta permite tener en la parte derecha de la regla formas típicas de las
expresiones regulares, como por ejemplo el símbolo “*”.
A partir de este momento, en los ejemplos de gramáticas que aparecerán, se usarán

símbolos en minúscula para denotar nombres de regla y símbolos en mayúscula para
denotar los tokens del lenguaje.
Un ejemplo sencillo de gramática suponiendo que tan sólo queremos reconocer un

subconjunto reducido de programas en nuestro lenguaje CL, detallado en el capítulo 5,
conteniendo tan sólo declaraciones de variables tipo entero, y con instrucciones de
asignación sería la siguiente:
program: PROGRAM dec_vars l_instrs ENDPROGRAM;

dec_vars: VARS (IDENT INT)* ENDVARS;
l_intrs: (IDENT ASIG expr)*;
expr: IDENT | INT;
Figura 2.9 - Ejemplo de gramática
program, dec_vars, l_intrs y expr son lo que llamaremos reglas o producciones

de la gramática.
PROGRAM, ENDPROGRAM, VARS, ENDVARS, IDENT

e INT son tokens o símbolos
terminales que se podrían declarar de la siguiente forma:
PROGRAM: „program‟;
ENDPROGRAM: „endprogram‟;
VARS: „vars‟;
ENDVARS: „endvars‟;
ASIG: „:=‟
IDENT: [A-Za-z][a-zA-Z0-9]*;
INT: [1-9][0 -9]* | 0;
Figura 2.10 - Definición de tokens de la gramática
Esta gramática permitiría reconocer programas como el que se muestra en la siguiente

figura:

program
vars
a int
b int
endvars
b := 8
a := b
endprogram
Figura 2.11 - Programa reconocible por la gramática de la Figura 2.9
A partir de la gramática y siguiendo los pasos del algoritmo de reconocimiento

podremos generar el Parse Tree característico de esa derivación y también, el AST
correspondiente.
2.3.2.2. Parse Tree
Un árbol de derivación es una representación gráfica que muestra la forma en la

que el símbolo inicial de una gramática deriva una entrada concreta.
Por ejemplo, para el caso de la gramática del apartado anterior (Figura 2.9), el árbol de
derivación de un programa, sería:

Figura 2.12 - Árbol de derivación
Así pues, como podemos observar, un árbol de derivación cumple que tiene como raíz
el símbolo inicial de la gramática y como hijos los símbolos de la producción de aquella
regla, y así recursivamente para cualquier símbolo del árbol que no sea un token.
Una gramática puede dar lugar a más de un árbol de derivación para una misma entrada.
En este caso, diremos que nuestra gramática es ambigua, lo cual no es deseable, siendo
éste uno de los principales problemas con los que se encuentra el Parsing. Dada una
gramática ambigua, el algoritmo de Parsing no puede decidir qué alternativa debe
seguir para conseguir el reconocimiento de la entrada. En la mayoría de ocasiones las
gramáticas reconocidas como ambiguas pueden reescribirse para eliminar el problema.
Veamos un ejemplo común de ambigüedad con la estructura if-then-else de los

lenguajes de programación.
Dada la siguiente gramática:

prop_if: IF expr THEN prop_if |

IF expr THEN prop_if ELSE prop_if |
p
expr: a
IF: if
ELSE: else
THEN: then
Figura 2.13 - Ejemplo de ambigüedad gramatical
Para la entrada:
if a then if a then p else p
Figura 2.14 - Entrada if/then/else ambigua
Existen dos árboles de derivación posibles:
Figura 2.15 - Árbol de derivación if/then/else: Opción 1

Figura 2.16 - Árbol de derivación if/then/else: Opción 2
Como se puede observar, en este ejemplo estamos tratando con una gramática ambigua
que dado un ejemplo de código como el mostrado, no sería capaz de decidir a cuál de
los dos if, pertenece el else. Por este motivo, los lenguajes de programación fuerzan el
uso de palabras clave como endif o el símbolo “}” de manera que nos permitan
diferenciar en los casos como el expuesto.
2.3.2.3. Abstract Syntax Tree
Los ASTs nos permiten guardar en forma de árbol las instrucciones y

expresiones del programa a compilar. Éste nos permite expresar la estructura del
programa, de manera que cada nodo representa una construcción del código fuente
eliminando aquellos elementos innecesarios como pueden ser el azúcar sintáctico,
paréntesis, corchetes... puesto que todo ello está implícitamente especificado en el
AST.
El AST es la nueva representación interna del programa inicial y contiene la

información que pasaremos a la siguiente etapa del compilador, el Análisis Semántico,
y en ellos ya hemos descartado toda aquella información no relevante para las
comprobaciones posteriores que se deberán realizar.
Volvamos al ejemplo de la Figura 2.11. El AST correspondiente a este programa es el

siguiente:

Figura 2.17 - AST del programa de la Figura 2.11
2.3.2.4. FIRST y FOLLOW
Para construir el árbol de derivación top-down es necesario expandir las reglas.

A la hora de decidir cómo expandir un determinado símbolo de una gramática, el
algoritmo lo hace basándose en el token de entrada y la información precalculada que
contienen los conjuntos FIRST y FOLLOW.
Así pues, definiremos los conjuntos FIRST y FOLLOW como [1]:
 FIRST. Definimos el conjunto FIRST(α) como el conjunto de terminales que

encabezan las cadenas derivadas de α, siendo α cualquier cadena de símbolos
gramaticales.
 FOLLOW. Se define FOLLOW(A), para el símbolo no terminal A, como el

conjunto de terminales a que pueden aparecer inmediatamente a la derecha de A
en alguna forma de derivación que comienza en el símbolo inicial de la
gramática.
Estos conjuntos se calculan para toda la gramática y se utilizarán en la construcción de

los algoritmos de Parsing.
2.3.2.5. Algoritmos de Parsing
Una vez introducidas las herramientas principales, pasamos a ver cómo

funcionan los algoritmos de Parsing.

El objetivo del Parser es reconocer la estructura de la entrada, es decir, debe ser capaz
de generar un árbol de derivación para ella. Se explicarán brevemente algoritmos de
Parsing lineal, es decir, que recorren la entrada de izquierda a derecha una única vez sin
posibilidad de reconsiderar las decisiones tomadas.
La información que se va a considerar para tomar esas decisiones es el único token

visible en cada momento, llamado token de lookahead o token en curso. Éste empieza
siendo la primera palabra de más a la izquierda de la entrada y acaba siendo el último
símbolo que nos queda. Por ejemplo, dada la definición:
instr: IDENT ASIG IDENT;
Figura 2.18 - Expresión de una gramática
El primer token de lookahead sería IDENT y continuaría con ASIG hasta llegar al último,
IDENT.
Existen dos tipos diferentes de Parsers lineales. En ambos casos la lectura de la entrada
se realiza de izquierda a derecha, símbolo a símbolo.
2.3.2.5.1. Análisis Descendente(LL)
Son los más intuitivos y muy habituales ya que permiten construir de manera sencilla
Parsers eficientes. Estos Parsers empiezan creando el árbol de derivación por la raíz y
continúan con los hijos de manera recursiva. Parten del símbolo inicial de la gramática y
van derivando en función del siguiente símbolo que están analizando sin hacer
backtracking, sino que simplemente observan los conjuntos FIRST y FOLLOW para
tomar las decisiones acertadas. Las gramáticas reconocidas por este tipo de Parsers
reciben el nombre de gramáticas LL. Los Parsers LL se corresponden normalmente con
los creados manualmente.
A modo gráfico podemos entender este algoritmo como que el árbol se monta de arriba
abajo, es decir, de raíz a hojas. Esto mismo es lo que hace que sean algoritmos mucho
más intuitivos.
El pequeño problema con el que nos podemos encontrar es que en ocasiones hay que
modificar las gramáticas debido a problemas como la recursividad por la izquierda o la
no factorización por la izquierda. Estas características de la gramática no suponen
ningún problema si lo que queremos es construir un Parser ascendente (LR).
Los Parsers de Análisis Descendente utilizan métodos predictivos, lo cual indica que
dado un token de lookahead, el Parser debe conocer cuál es el siguiente paso a seguir
en el reconocimiento.

Hasta el momento nos hemos referido a Parsers LL y LR, pero en realidad éstos se
denotan como LL(k) siendo k el número de tokens de lookahead. k siempre es un entero
mayor que cero. Así pues, nos referiremos a los Parsers que tan sólo contemplan un
token de lookahead como LL(1) o LR(1).
Sin embargo, los Parsers generados por ANTLR v3, son Parsers LL(*), donde el “*”
indica que hay un número indeterminado de tokens de lookahead. Es decir, que el valor
de “*” tan sólo se conoce en tiempo de ejecución.
Análisis Ascendente(LR)
En realidad estos permiten reconocer un mayor número de lenguajes que los LL,
pero no son tan sencillos de implementar ni de comprender. En este caso, sí que pueden
trabajar con gramáticas con recursividad tanto izquierda como derecha. Las gramáticas
reconocidas por este tipo de Parsers reciben el nombre de gramáticas LR. Este tipo de
algoritmo es usado habitualmente por las herramientas automáticas de generación de
Parsers como Yacc [3] o Bison [4].
Al contrario que el análisis LL, el LR construye sus árboles de derivación de abajo a

arriba, es decir, desde las hojas hacia la raíz. Como ya se puede intuir, esto es mucho
menos sencillo puesto que dado un conjunto, hemos de aplicar las reglas en sentido
inverso, es decir, reduciendo la parte derecha de la regla a la parte izquierda.
Los Parsers de Análisis Ascendente se pueden entender como un proceso de reducción

en el que partimos de un conjunto de tokens que acabaremos reduciendo al símbolo
inicial de la gramática. Entendemos por símbolo inicial de la gramática el símbolo de la
primera regla que genera la derivación. Estos algoritmos también reciben el nombre de
Shift-Reduce puesto que estas son las dos acciones posibles en cada paso del análisis.
Ahora vamos a ver un ejemplo claro de cómo sería la derivación de una palabra
aplicando un análisis y otro. Supongamos la siguiente gramática:
S: aAbB
A: b | c
B: d
Figura 2.19 - Gramática de ejemplo para Parsing
Y la palabra : w = abbd
La derivación para un algoritmo LL sería la siguiente:

S  aAbB  abbB  abbd
Figura 2.20 - Derivación aplicando Parsing LL
Mientras que para un algoritmo LR sería esta:
abbd  aAbd aAbB S
Figura 2.21 - Derivación aplicando Parsing LR
Como ya hemos podido comprobar, el análisis LL es mucho más sencillo según nuestra
forma de razonar.
Otro tema a tener en cuenta a la hora del análisis LL o LR, es el número k de tokens de
lookahead que vamos a considerar en un momento determinado para decidir la acción
llevada a cabo en cada paso. En general, nos referiremos a los algoritmos LL y LR
como LL(k) o LR(k), donde k es siempre un entero mayor o igual a 1.
Si el analizador se encontrara en el caso que para el token de lookahead en curso, no

hubiera ninguna acción posible a aplicar, el compilador debería remitir un error al
usuario.
Ante los posibles errores que pueda encontrar el compilador, éste puede actuar
aplicando diferentes protocolos:
 Inventar el o los tokens que faltan para así poder continuar con el análisis.
 Continuar con el análisis buscando un token que pueda reconocer
 Continuar con el análisis hasta que encuentra un token delimitador.
Para remitir la información del error al usuario, el compilador almacena datos como la
línea en la que tiene lugar el error, el motivo del fallo y si es necesario, sigue algún
protocolo de recuperación como los antes explicados.
Además de la información relacionada con los errores, el Análisis Sintáctico construye

el AST correspondiente al código fuente.

2.4. Análisis Semántico

El Análisis Semántico es la siguiente fase en el recorrido que estamos realizando
por la estructura de un compilador. Éste presenta diferencias importantes con el Scanner
y el Parser. En este punto final de la etapa de análisis, se comprueba que el programa
de entrada cumpla una serie de propiedades no estructurales del lenguaje.
El lenguaje CL para el que construiremos el compilador es un lenguaje con tipificación

estática, es decir, se puede calcular el tipo de toda expresión del programa en tiempo de
compilación aplicando unas determinadas reglas de inferencia de tipos.
A diferencia del Parser, donde existen herramientas que permiten generar el código
automáticamente a partir de la gramática del lenguaje, aquí normalmente es el
programador el encargado de implementar la mayor parte del código del analizador
semántico.
2.4.1. Funcionamiento y Objetivos

El Análisis Semántico, también conocido como Type Checking, se encarga de
comprobar que el código a compilar, representado en forma de AST, cumple las reglas
semánticas del lenguaje en el que está escrito. Si no las cumple, reportaremos los errores
al usuario. Se debe intentar no indicar aquellos errores que son consecuencia de errores
semánticos previos.
Existen una gran cantidad de verificaciones que realizar y que dependen básicamente de
la complejidad del lenguaje a analizar. Algunas de ellas son las siguientes:
 Si los identificadores están definidos.
 Si los tipos en ambos lados de una asignación son equivalentes o existe

coerción de tipos.
 Si las llamadas a funciones se refieren realmente a funciones.
 Si la expresión que encontramos en las sentencias de tipo if y while son

booleanos.
 Si los identificadores usados como variables se corresponden con nombres de

variables declaradas.
 Si estamos haciendo uso de variables y parámetros declarados dentro de un

ámbito visible desde el punto del programa donde nos encontramos.

 Si los tipos de los operandos de cada uno de los operadores se corresponde con
el tipo esperado.
 Si las expresiones usadas en la parte izquierda de una asignación son

referenciables.
 Si la llamada a una función o procedimiento es correcta en cuanto al tipo y

número de parámetros con los que está definida.
 ....
El código del analizador semántico se encarga de recorrer el AST que recibe de la etapa
previa (Análisis Sintáctico) e ir añadiendo a sus nodos más información en cada paso
que da. Es lo que llamamos decoración del AST. Esta información va a ser usada tanto
por el propio Análisis Semántico como por posteriores etapas del compilador.
Se puede implementar mediante un código recursivo que recorre el AST siguiendo una
estrategia bottom-up que va añadiendo la información y que a medida que se deshace la
recursividad va realizando las comprobaciones de corrección.
2.4.2. Sistema de Tipos

El diseño de un analizador semántico se basa principalmente en la información
sobre las construcciones sintácticas del lenguaje, la noción de tipos y la asignación de
tipos a las construcciones del lenguaje.
Cada expresión del lenguaje tiene asociado un tipo que puede ser básico o estructurado.
Los tipos permitidos por el lenguaje CL son los siguientes:
 Tipos básicos predefinidos: entero y booleano.
 Tipos estructurados a partir de los constructores: arrays, structs y punteros.
 Tipos de los bloques: procedimientos y funciones.
 Nombres de tipos definidos por el usuario o typenames.
El analizador semántico implementa un sistema de inferencia de tipos para el trabajo

que debe realizar. El sistema de inferencia de tipos permite calcular el tipo de una
construcción (una expresión) a partir del tipo de los operandos.

Otra información importante que debemos calcular es si una expresión es o no

referenciable, es decir, si tiene sentido hablar de su dirección de memoria o modificar el
valor que contiene.
Además, para poder definir un sistema de tipos, debemos tener claro también cuándo
dos tipos son equivalentes. Existen principalmente dos nociones de equivalencia de
tipos:
 Equivalencia estructural. En este caso decimos que dos tipos son equivalentes
si y sólo si son estructuralmente idénticos.
 Equivalencia de nombres. Para la equivalencia de nombres, dos tipos son

equivalentes si son los mismos tipos básicos o si son nombres de tipos y son el
mismo.
Supongamos la siguiente declaración:
types
tA array[10] of int
tB array[10] of int
endtypes
vars
a tA
b tB
endvars
Figura 2.22 - Ejemplo de equivalencia de tipos
Para el caso de la equivalencia estructural, a y b tienen tipos equivalentes y por tanto,

se puede realizar una asignación entre ellas. Sin embargo, para el caso de la
equivalencia por nombre no la tienen, puesto que a y b deberían ser ambos o del tipo tA
o del tB para poderse realizar la asignación.
Aparte de lo que estrictamente entendemos por tipo deberemos tener en cuenta otra
clase de información sobre los identificadores, por ejemplo, la clase de símbolo, si es
referenciable, el tipo de visibilidad y el ámbito en el que están declarados.
La estructura de ámbitos y el tipo de vinculación estática o dinámica son característicos

de cada lenguaje de programación. CL permite definir ámbitos de forma anidada y el
tipo de vinculación es estática. Se detallarán más estos aspectos en el capítulo 5.
Toda esta información relativa a cada símbolo deberá ser recogida en una estructura de
datos adecuada para su uso. Denominaremos a esta estructura Tabla de Símbolos.

2.4.3. Tabla de Símbolos

La Tabla de Símbolos almacena toda la información relativa a los símbolos y los
ámbitos donde han sido declarados. Recibe entradas a medida que nos encontramos con
declaraciones de símbolos y, posteriormente, se realizan consultas sobre ella para
realizar las comprobaciones en el uso de esos símbolos.
Antes de realizar la inserción de un nuevo símbolo en la tabla, se deberá comprobar que

no haya sido introducido previamente en el mismo ámbito y asegurar que su tipo sea
correcto (para el caso de los nombres de tipo hay que verificar que existe como tal).
Dado que una de la información más relevante para la parte que estamos tratando es el
ámbito al que pertenece un símbolo (identificador), la tabla de símbolos organizará su
información de manera que tendremos una tabla para cada ámbito del programa. Por
tanto, la Tabla de Símbolos realmente consiste en una pila de ámbitos. Dentro de cada
ámbito estarán declarados sus identificadores.
2.4.4. Decoración de ASTs

A partir del AST procedente de la fase de Análisis Sintáctico, durante el Análisis
Semántico se van decorando algunos nodos del árbol con información a considerar en
las comprobaciones posteriores.
Según la clase de nodo, deberá guardar una información u otra. Por ejemplo, si el nodo
corresponde a una subexpresión deberá guardar la información del tipo de la expresión
y si ésta es referenciable o no.
A continuación se muestra el AST y AST decorado resultado del Análisis Semántico

sería del siguiente programa fuente:
program
vars
x int
a array[5] of int
endvars
x := 3
a[3] := x + 1
endprogram
Figura 2.23 - Programa de ejemplo

Figura 2.24 - AST del programa de la Figura 2.23
Figura 2.25 - AST decorado del programa de la Figura 2.23

Como podemos observar, el AST decorado es igual en estructura que el AST sin
decorar. La única diferencia es que ahora, en cada nodo, hemos añadido información
sobre el tipo y la referenciabilidad de las expresiones.
En la Figura 2.25 se denota si la expresión de un nodo determinado es referenciable

mediante el uso de la indicación [R]. Como se puede observar, en el ejemplo aparecen
como referenciables los identificadores usados en las instrucciones.

Capítulo 3. Conceptos Teóricos: Etapas de Síntesis
3. Conceptos Teóricos: Etapas de Síntesis

Como ya se comentó en la introducción, un compilador se divide en tres grandes
etapas: Front-end, Middle-end y Back-end. Estas tres grandes etapas, también se pueden
dividir en etapas de análisis o de síntesis.
Nos referimos por análisis a aquella etapa encargada de validar la corrección del
programa fuente, mientras que las etapas de síntesis tienen como objetivo la traducción
del código fuente a otros lenguajes. Así pues, en este capítulo hablaremos de las etapas
de Middle-end y de Back-end.
En el Capítulo 2 hemos tratado las fases en las que se divide la etapa de análisis (Front-
end), y ahora hablaremos de las que componen la etapa de síntesis (Middle-end, Back-
end).
La etapa de síntesis se divide en:
 Middle-end. Las fases que componen el Middle-end tienen como objetivo

traducir a un código intermedio. Estas fases son:
o Generación de código intermedio.
o Optimización de código intermedio.
 Back-end. Esta etapa tiene el mismo objetivo que la anterior, pero en este caso,
se traduce a un código objeto.
o Generación de código objeto.
o Optimización de código objeto.
A pesar de que para poder entender el funcionamiento de la etapa de análisis hubo que
introducir muchos conceptos teóricos, no ocurre lo mismo con la de síntesis. El motivo
de esto es que el trabajo llevado a cabo en la etapa de síntesis está mucho menos
sistematizado, ya que buena parte de la implementación corre a cargo del programador.
En la etapa de análisis, el programador se encarga de especificar unas reglas de análisis
y, herramientas como ANTLR se encargan de generar el código del Lexer y Parser.
Para la generación de código, ANTLR también proporciona mecanismos como las Tree
Grammar y los Tree Parser que facilitan este proceso.

3.1. Generación de Código Intermedio

En esta fase se centra la principal parte de este proyecto. La principal motivación
a la hora de generar un código intermedio es producir un programa en un lenguaje más
sencillo que el fuente, pero manteniendo siempre la semántica del lenguaje inicial. Para
ello, previamente se definirá un código intermedio al cual traducir y, posteriormente, se
definirá la traducción a ese código de manera que preserve su significado inicial.
Los objetivos de esta fase son conseguir un código que permita la reusabilidad de varias
etapas del compilador, ya que cuando cambiamos de arquitectura, sólo tendremos que
modificar la traducción de código intermedio a código objeto; pero también, simplificar
el desarrollo de un compilador dividiéndolo en tareas. A pesar de todo ello, el objetivo
fundamental es el de poder aplicar técnicas de optimización independientes de la
arquitectura.
El proceso de traducción a código intermedio se define a partir del AST decorado que
recibimos de la etapa de Análisis Semántico, considerando que se han superado las fases
previas y que contamos con un código de entrada correcto.
De forma parecida al Análisis Semántico, el Tree Parser correspondiente al generador

de código trabaja recursivamente sobre el AST previamente decorado. Esta tarea puede
ser más o menos compleja dependiendo de la sintaxis del código intermedio a generar y
también, de si queremos ir realizando ciertas optimizaciones de código ya en esta fase.
Habitualmente se trabaja con una representación intermedia en forma de código de tres

direcciones. Un código de tres direcciones es una secuencia de instrucciones del estilo:
op1 := op2 op op3
Figura 3.1 - Ejemplo de código de tres direcciones
Donde op1, op2 y op3 denotan los operandos, que pueden ser identificadores,
registros temporales o constantes; y op denota un operador cualquiera del lenguaje:
aritmético, lógico...
Recibe el nombre de código de tres direcciones porque se especifican dos direcciones

para los operandos y una para el resultado.
Para generar el código intermedio en primer lugar debemos partir de la definición

formal del código intermedio deseado. A partir de aquí, la traducción consiste en aplicar
patrones de traducción para cada una de las estructuras del lenguaje.

Los patrones para la generación del Z-Code se presentarán en el capítulo 5, aunque

antes presentaremos conceptos clave que nos permitan más adelante entender la
traducción seguida.
3.1.1. Entorno en tiempo de ejecución

Para poder finalmente ejecutar el código objeto al que se ha traducido el
programa fuente, es necesario disponer de un entorno de ejecución. Los programas en
código objeto se ejecutarán en una máquina virtual.
En este apartado se describirá cómo es ese entorno en tiempo de ejecución, puesto que
es necesario tener en cuenta algunos de esos conceptos a la hora de definir la traducción.
El entorno de ejecución de un programa de código intermedio en una máquina virtual,

debe tener en cuenta las siguientes cuestiones:
 Estructura y gestión de la memoria
 Registros físicos virtuales
 Memoria estática y memoria dinámica
 Heap o montículo
 Registros específicos como el PC, SP o BP
 Conjunto de instrucciones con su correspondiente semántica
Para que un programa se ejecute en una máquina virtual, el contexto debe encargarse de
realizar las siguientes tareas:
 Distribución y asignación de espacios de almacenamiento para los elementos

nombrados en el programa
 Mecanismos de acceso a variables
 Enlaces entre procedimientos y funciones
 Mecanismos para el paso de parámetros
 ....
Principalmente trataremos los temas de gestión de memoria y el acceso a variables y

datos.

3.1.1.1. Gestión de Memoria
La representación de un programa en tiempo de ejecución en el espacio de

direcciones está formada por el área de datos y el espacio de instrucciones.
Dentro de este espacio de direcciones contaremos con espacios de tamaño fijo, es decir,
con una gestión estática y, con espacios de tamaño variable, con una gestión dinámica.
Consideraremos que en memoria estática se ubican objetos que tan sólo tienen una
instancia y un tamaño acotado. En ella se encuentran el código, las variables globales,
cadenas de caracteres (strings) y constantes.
Hablaremos de memoria dinámica para referirnos a la pila y al montículo. La pila

almacena estructuras de datos, generadas durante las llamadas a procedimientos y
funciones. El montículo o heap, administra el espacio de memoria dinámica con el que
trabajan los programadores de forma discrecional. Existen lenguajes de programación,
como CL, que permiten que el programador solicite y libere memoria (instrucciones new
y free) bajo su responsabilidad.
Existe un gestor que se encarga de administrar el espacio ocupado por el montículo.

Para ello, el gestor reserva y libera espacio del heap cuando se necesita. También, en
caso de acabarse el espacio, se encarga de detectar aquellos espacios que no están
siendo utilizados,...
Las estructuras de datos que almacena la pila reciben el nombre de registros o bloques
de activación. Cada bloque de activación contiene información relativa a un
procedimiento o función como puede ser el valor del PC al que volver tras la llamada a
una función/procedimiento. En un registro de activación también encontraremos espacio
para los datos cuya vida está ligada a la llamada correspondiente; por ejemplo, variables
locales y parámetros.
Veamos una figura que ilustra el estado de la memoria en tiempo de ejecución, tal como
se muestra en la bibliografía [1]:

Figura 3.2 - Estado de la memoria en tiempo de ejecución
A pesar de que la pila crece hacia direcciones inferiores de memoria, en este apartado
supondremos que lo hace hacia superiores para poder usar desplazamientos positivos y
facilitar el entendimiento de los conceptos.
3.1.1.2. Bloque de Activación
Como bien se ha comentado, cada vez que se ejecuta una llamada a un

procedimiento o función, se debe montar un bloque de activación y, cuando la llamada
acaba, se debe desmontar este mismo bloque.
Existen instrucciones de lenguaje ensamblador encargadas de montar y desmontar los

bloques de activación. En CL, la instrucción CALL, realizada cuando se hace la llamada
a un procedimiento o función, se encarga de crear un nuevo bloque de activación,
mientras que el RETU se encarga de desmontarlo.
Supongamos el siguiente ejemplo de código CL:

program
vars
a int
b int
endvars
procedure P(ref pa int)
procedure P1(ref p1a int)
p1a := p1a + b
P(p1a)
writeln(p1a)
endprocedure
pa := pa + a
P2(pa)
P1(pa)
writeln(pa)
endprocedure
procedure P2(ref p2a int)
p2a := 1
writeln(p2a)
endprocedure
a := 1
b := 2
P(b)
endprogram
Figura 3.3 - Programa en CL
Como podemos observar en la Figura 3.3 existen procedimientos declarados dentro de

otros procedimientos. Veamos la estructura de bloques del programa en forma de árbol:
Figura 3.4 - Estructura en árbol del programa de la Figura 3.3
La Figura 3.4 muestra la representación de la estructura estática de los procedimientos

del programa del ejemplo. Representamos donde se ha definido cada procedimiento y
por tanto, la relación entre ellos. Por ejemplo, P es el padre estático de P1.

Siguiendo una regla de visibilidad habitual de lenguajes que permiten definir bloques
anidados, dentro de un procedimiento/función se puede llamar a cualquier otro
procedimiento/función declarado localmente o bien declarado por alguno de sus
ancestros. Por lo tanto, un procedimiento o función siempre puede llamar a todo
procedimiento o función hijo o hermano.
Como hemos dicho, unos procedimientos o funciones pueden llamar a otros/as y por
tanto, deberemos activar un bloque de activación para cada llamada. Podemos
representar estas activaciones mediante lo que denominaremos árboles de activación.
Un árbol de activación es una estructura en forma de árbol donde cada nodo representa
una activación durante la ejecución y la raíz representa el programa principal que inicia
la ejecución de todo el programa.
Un posible árbol de activación para el programa del ejemplo anterior sería el de la

Figura 3.6. El orden dentro de él se muestra de izquierda a derecha.
El árbol de la figura refleja el siguiente orden de las llamadas en tiempo de ejecución:
programa principal  P  P2  P1
Figura 3.5 - Orden de llamadas en tiempo de ejecución de la Figura 3.3
En este árbol, P es el padre dinámico de P2. Así pues, podemos observar que las
relaciones jerárquicas estáticas no son las mismas que las dinámicas.
Figura 3.6 - Árbol de activación del programa de la Figura 3.3

Como podemos observar, en un nodo para la activación del programa principal, el hijo
corresponde con la activación del procedimiento al cual se llama mediante la activación
del programa principal. Lo mismo ocurre con P y sus hijos P2 y P1.
Para poder implementar las llamadas, un procedimiento o función debe poder apuntar a
su padre estático y dinámico. El apuntador dinámico nos permite volver al punto
anterior a la llamada. Por su parte, el apuntador estático permite acceder a los datos que
son accesibles en ese bloque de activación.
La siguiente figura ilustra el crecimiento de la pila durante tiempo de ejecución del

programa de la Figura 3.3:
Figura 3.7 - Crecimiento de la pila para el ejemplo de la Figura 3.3
El bloque de activación del programa principal será siempre el de posiciones más bajas,
y a medida que se van realizando sucesivas llamadas, la pila irá creciendo con los
bloques de activación de los otros procedimientos.
Los bloques de activación se montan tanto por el procedimiento/función llamado/a

como por el/la que llama. En concreto, el procedimiento o función que llama se encarga
de reservar espacio para el valor de retorno (en caso de que se llame a una función) y
también, de colocar los parámetros reales y el static-link en la pila. La instrucción CALL
se encarga de ubicar en pila el valor del registro PC y del puntero dinámico. El resto de
acciones, como por ejemplo salvar el estado, se encarga de llevarlas a cabo el
procedimiento o función al que se ha llamado.
El proceso de desmontar la pila es simétrico al de montar, siguiendo como criterio que

quien pone algo en la pila también lo quita.

La Figura 3.8 inferior muestra en detalle qué información, y en qué orden, contiene un
bloque o registro de activación montado por las instrucciones del Z-Code:
Figura 3.8 - Bloque de activación en Z-Code
 El primer espacio ubicado es el reservado para el valor de retorno de una

función. Recordemos que los procedimientos no tienen valor de retorno.
 Al realizarse la llamada, el procedimiento o función que hace la invocación se

encarga de colocar los parámetros en la pila. Éstos se apilarán de derecha a
izquierda de la forma en la que aparecen declarados en la llamada a la función o
procedimiento.
 El enlace estático permite acceder a datos no locales definidos en otros

procedimientos y funciones, pero que son visibles desde el procedimiento
llamado.
 La dirección de retorno es el Old Program Counter, que indica cuál es la

dirección de la instrucción a la que regresar cuando se acabe la llamada.
 El enlace dinámico apunta al bloque de activación del procedimiento que hizo la

llamada.

 Las variables locales ubicadas en la pila son las pertenecientes al procedimiento

de ese registro de activación concreto, siendo el procedimiento o función
llamado en el/la que las coloca en la pila.
 Finalmente, se reserva en pila un espacio adicional de memoria gestionado por

el compilador como una variable local especial, utilizado para realizar copias de
datos o para poner valores de retorno de funciones. Este espacio de memoria
recibe el nombre de aux_space. Más adelante se explicará en más detalle este
concepto.
3.1.1.3. Enlaces Estáticos
Los enlaces estáticos o enlaces de acceso permiten localizar datos que no se

encuentran en nuestro registro de activación, pero a los cuáles sí tenemos acceso puesto
que son visibles desde el ámbito donde nos encontramos.
Para poder acceder a una variable o parámetro no local haremos uso de los enlaces
estáticos, que a partir de ahora denominaremos static_link. El static_link siempre apunta
al bloque de activación del padre estático, en concreto al correspondiente a la activación
más reciente.
Dado un procedimiento o función P y un identificador X (variables, procedimiento,..),

denominaremos Diferencia de Niveles para acceder a X, al número de niveles que hay
que subir en la estructura estática de bloques para ir desde el procedimiento o función P
al bloque donde está declarado el identificador X.
Cuando un bloque llama a su procedimiento hijo, la diferencia de niveles es 0. Cuando

se trata de una llamada recursiva o a un hermano, la diferencia es de 1 y, cuando la hace
a un bloque del nivel de su padre, la diferencia es 2 y así recursivamente.
Volvamos al ejemplo de la Figura 3.3 y veamos cómo es la pila para la secuencia

dinámica de llamadas de la Figura 3.5:

Figura 3.9 - Pila para la secuencia de llamadas de la Figura 3.3
Como ya se ha comentado, para acceder a un objeto no local se hará uso del static_link,
pero además, se utilizará el valor Dif_niveles. Éste nos indicará cuál es el número de
indirecciones a realizar para llegar al ámbito del objeto, siempre que éste sea mayor que
0.
Veamos los diferentes casos que podemos encontrarnos a la hora de acceder a un objeto
no local:
 Dif_niveles =1. Si durante la ejecución del procedimiento P hay una referencia a

una variable o parámetro definido en el programa principal, deberemos de
acceder a tal identificador de la manera:
temp := static_link
temp := temp + offset(identificador)
Figura 3.10 - Cálculo del static_link cuando Dif_niveles = 1
 Dif_niveles = 2. Si la diferencia de niveles es dos, por ejemplo, acceder a un

identificador definido en el programa principal desde P1, el acceso al
identificador sería de la forma:

temp := *static_link
Figura 3.11 - Cálculo del static_link cuando Dif_niveles = 2
 Dif_niveles = n > 2. Como regla general, el acceso a un identificador no local

será de la siguiente forma que muestra la figura inferior, siendo n el valor que
representa la diferencia de niveles.
temp := *static_link
(temp := *temp)n-1
Figura 3.12 - Cálculo del static_link cuando Dif_niveles > 2
3.1.1.4. Uso del espacio auxiliar
El llamado aux_space es una parte del bloque de activación reservado para

realizar copias de objetos de tipos no básicos. Necesitaremos aux_space siempre que
queramos copiar el valor de arrays, structs o tipos definidos.
La cantidad de espacio necesario viene determinado por el tamaño de los objetos a

copiar y lo calcula el compilador. Necesitaremos aux_space para:
 Paso de un parámetro por valor de tipo no básico, para hacer una copia del
parámetro real.
 Retorno de funciones de tipo no básico, para guardar el resultado de retorno de

una función.
Aux_space también se puede usar para otras instrucciones que, aunque no definidas para
el lenguaje CL, se podrían implementar.
Así pues, cuando necesitemos trabajar con el valor de un objeto de tipo no básico
realizaremos una copia en el aux_space del bloque de activación donde necesitamos ese
valor.
Implementaremos la copia de la siguiente forma:

calculoDireccion(IDENT, temp2)
temp1 := aux_space
temp1 := temp1 + offsetAux_space
copy temp2 temp1 sizeOf(IDENT)
Figura 3.13 - Copia de una variable de tipo no básico utilizando aux_space
Como podemos ver en la figura anterior, lo que se hace es buscar la posición de

memoria donde está ubicado el valor original. A continuación, cargamos la dirección de
memoria de aux_space, es decir, la dirección a partir de la cual se considera espacio
auxiliar para copias.
Finalmente, se realiza la copia de la dirección de memoria del valor original a la del

aux_space de un número determinado de bytes.
Internamente el compilador define aux_space como una macro que comprende un

conjunto de instrucciones para acceder a las posiciones de memoria donde éste se ubica.
Aux_space es un dato con el que cuenta toda función o procedimiento de igual manera
que lo es static_link. Su valor es el número máximo de bytes que necesitará una
instrucción para realizar copias en el ámbito de ese procedimiento o función, es decir,
que su valor se inicializa para cada ámbito. Dado que dentro de una misma instrucción
de alto nivel podemos necesitar realizar más de una copia, necesitamos de un control del
espacio ocupado hasta ese determinado momento, offsetAux_space.
OffsetAux_space es un valor que se inicializa para cada instrucción de alto nivel. Este
valor se actualiza a medida que se encuentra con situaciones en las que es necesario usar
aux_space dentro de una misma instrucción. Como se puede observar en la Figura
3.14, la instrucción b := f(f(a,a),a) realiza más de una copia. offsetAux_space se
encarga de que en el momento de realizar cada una de las copias, indicar la posición de
memoria en la que se realiza.
Veamos el ejemplo ya comentado de una instrucción que necesita más de una copia en
aux_space:

program
vars
a array[2] of int
b array [2] of int
endvar
function f(val a1 array[2] of int, val a2 array[2]) return
array[2] of int
return a
endfunction
a[1] := 1
a[2] := 2
b := f(f(a,a),a)
endprogram
Figura 3.14 - Programa con variables de tipo no básico
La instrucción b := f(f(a,a),a) necesita tres copias en aux_space; una para cada

parámetro pasado. Además, también se realizan dos reservas de espacio en aux_space
para copiar el retorno de las funciones. Por lo tanto, el total de copias realizadas será
cinco.
En total, el espacio reservado en aux_space para la instrucción será de 40 bytes, ya que

necesitamos 8 bytes para cada valor.
3.1.1.5. Administración del montículo
El montículo o heap es el espacio de memoria que usamos para ubicar los datos
que tienen una vida indefinida, o hasta que el programador lo determina de forma
explícita en el código.
En CL, estos datos serán los creados por la función new y eliminados por la función
free. La diferencia entre estos datos y las variables o parámetros es que una vez
desaparece el bloque de activación en el que han sido definidos no desaparecen, ya que
están ubicados en una porción de memoria que trabaja de manera diferente a la pila.
La diferencia con la pila reside en que el heap almacena la información creada en

tiempo de ejecución. Además, los bloques de memoria son reservados y liberados de
forma arbitraria. Su reserva y tamaño es desconocido hasta el momento de ejecución.
El administrador de memoria se encarga de asignar y desasignar esta memoria. Esta

tarea la realiza un gestor interno que realiza diferentes acciones como la compactación
de bloques de memoria libres, eliminación de datos ya no utilizados...

3.2. Optimización de Código Intermedio

Como ya hemos comentado antes, uno de los motivos de generar un código
intermedio es el de facilitar la tarea de optimización de código, ya que este es el punto
en el que se realiza una de las dos optimizaciones de código.
Las optimizaciones realizadas en este punto son todas independientes de la arquitectura,

ya que trabajan sobre la representación intermedia, la cual no está basada en ninguna
arquitectura concreta.
El objetivo de la optimización de código es conseguir un código más eficiente en

tiempo y espacio, aunque principalmente se basa en la optimización temporal. Esta
optimización se potenció debido a la aparición dispositivos con menor memoria.
Existen muchas operaciones redundantes en un programa. En muchos casos el

programador es consciente de esta redundancia, puesto que repite cálculos por
considerar que es mucho más legible y directo volver a hacerlo. Además, se espera que
el compilador sea capaz de detectar estas redundancias y eliminarlas de manera que el
código objeto final sea lo más eficiente posible.
En el apartado de generación de código, también se producen ineficiencias debido a la

simplicidad a la hora de traducir el lenguaje de alto nivel en función de cómo se realiza
la traducción. Por ejemplo, muchas ineficiencias están motivadas por los accesos en
lenguaje de alto nivel a tipos que realmente son apuntadores a posiciones de memoria
como arrays o estructuras no básicas. En alto nivel, los accesos a las posiciones de
memoria de un array son del tipo A[i], pero como bien sabemos, ese acceso oculta
todo un conjunto de cálculos que se realizan en niveles más bajos de computación
(código intermedio y código objeto).
Por todo esto, es necesaria la eliminación de instrucciones a veces innecesarias o la

sustitución de instrucciones por otras más eficientes, ya que la abstracción de los
lenguajes de alto nivel introduce ineficiencias, en ocasiones voluntarias, pero en otras
involuntarias. De hecho, desde el punto de vista de ingeniería del software, hay que dar
prioridad a la comprensión, mantenimiento y desarrollo del código frente a la eficiencia.
Al hacer que el compilador optimice obtendremos la mejor solución, un código
mantenible y eficiente.
Hay que destacar el hecho que existen dos fases de optimización de código, una
independiente de la arquitectura, y otra, llevada a cabo en posteriores fases del
compilador, que sí que es dependiente.
A la hora de llevar a cabo la optimización de un código, primero se realiza un análisis

del flujo de control y del de datos, para después transformar el código. La
transformación debe garantizar el funcionamiento y corrección del código además de
preservar la semántica del programa inicial.

Para la optimización se aplican diferentes técnicas que no detallaremos puesto que ésta
no ha sido objeto de estudio de este proyecto, pero sí que veremos un ejemplo de
optimización para comprender mejor a que nos referimos.
Veamos dos ejemplos muy sencillos, en lenguaje de alto nivel, que contienen
claramente redundancias e ineficiencias.
int f (int x)
{
int y, z;
y = x + 1 ;
if(x == 2){
z = 2;
return x;
}
else if (x == 3){
z = 3;
return x;
}
else{
z = 1;
return x+1;
}
}
Figura 3.15 - Programa de ejemplo para optimizar
Como podemos observar este es un ejemplo muy obvio de código ineficiente, pero
realmente, las redundancias creadas en él, en códigos de extensiones grandes son muy
habituales.
Claramente existen dos redundancias a eliminar:
 return. Si nos damos cuenta, realmente en dos de los casos estamos

devolviendo lo mismo, x. En este caso, dado que el cuerpo de la sentencia
condicional no supone ningún cambio en el resultado o las acciones llevadas a
cabo por la función, simplemente reorganizando el código de otra manera,
podríamos evitar calcular dos veces el mismo valor.
Como ya se ha comentado, en este caso puede parecer una absurdez que un

programador implemente ese código, pero en realidad, esto es una práctica muy
habitual y de hecho, se realizan conscientemente para aportar legibilidad y
comprensión al código, siempre pensando en aplicaciones con gran extensión de
código. Por ejemplo, imaginemos casos en los que las expresiones condicionales
de cada alternativa son muy complicadas de reagrupar o simplemente, que

tenemos una gran casuística donde el código dentro de cada alternativa es muy
extenso.
 expresión x+1. El return x+1 no tiene mucho sentido si previamente ya hemos

calculado ese valor y, además, lo hemos guardado en una variable creada
explícitamente para ello. Lo más sencillo sería optar por retornar simplemente y
o bien, si no vamos a hacer uso de ese cálculo hasta el final del código,
evitarnos la creación de un variable y la realización del cálculo al inicio.
De nuevo, puede parecer algo absurdo pero en casos de funciones con gran
extensión de código puede ser un despiste habitual por parte del programador.
La siguiente figura muestra otro ejemplo de redundancia de cálculos. La sentencia for,

repite a cada iteración del bucle el cálculo 2*x. Este problema se puede solucionar
simplemente realizando la operación justo antes de entrar en el bucle y crear una
variable que almacene ese dato. La comparación dentro de la sentencia for se haría con
la variable creada.
int f2 (int x)
{
int j;
for(int i := 0; i < 2*x; i++){
A[i] := j
}
return j;
}
Figura 3.16 - Ejemplo de redundancia en los cálculos
A continuación se muestra un trozo de código en lenguaje de alto nivel que conlleva

redundancias. Esta vez, el programador, a priori, no es consciente de ellas. Y, además,
la solución no es viable si queremos mantener los principios de ingeniería del software.
....
while(i<10){
A[2*i] = i;
B[2*i] = i+1;
C[2*i] = A[i] + B[i];
}
....
Figura 3.17 - Ejemplo de redundancia de cálculos
A priori, podemos pensar que este código no contiene ninguna ineficiencia y, desde el
punto de vista de lenguaje de alto nivel, es cierto. Sin embargo, como hemos comentado

anteriormente, los accesos a tipos estructurados, como en este caso las arrays,
introducen muchas redundancias.
Si nos planteamos como se traduce el acceso A[i], B[i] o C[i], en un supuesto código
intermedio con temporales, éste es de la forma:
temp1 := calculoDireccion(A)
temp2 := valor(2*i) * tamañoElementos(A)
temp1 := temp1 + temp2
Figura 3.18 - Cálculo del acceso a una posición en una tabla
Este mismo cálculo se repetiría para B[i] y C[i] en todas sus ocurrencias a lo largo del
código.
Como podemos apreciar, el cálculo temp2 := valor(2*i) * tamañoElementos(A)

es constante durante el bucle. Y será igual para B y C, puesto que el valor de i es
constante durante una iteración del bucle y, además, el tamaño de los elementos de cada
array podemos asumir que es el mismo (contienen enteros).
Así pues, una optimización que realiza el compilador en esta etapa es, simplemente
realizar este cálculo una vez, y usar el registro temporal que almacena el valor cuando
sea necesario.
3.2.1. Optimización del Código Dividido en Bloques Básicos

El primer paso a llevar a cabo siempre a la hora de realizar optimizaciones de
código intermedio consiste en dividir el código en bloques básicos.
Un bloque básico es una secuencia de instrucciones tal que:
 El flujo de control sólo puede entrar en el bloque a través de la primera

instrucción del bloque.
 El flujo de control sólo puede salir del bloque a través de la última instrucción
del bloque.
Definiremos un header como la primera instrucción de un bloque básico. Habitualmente

vienen marcados por ser la primera instrucción de todo el código, la instrucción que
sigue a un salto o una instrucción destino de un salto.
El conjunto de bloques básicos se representan en forma de grafos dirigidos para poder

estudiar de mejor forma el flujo de datos y control.

Supongamos el siguiente trozo de código intermedio:
...
i := 0
j := 0
etiq_while:
if j > 10 goto etiq_endwhile
i := i + 2
t1 := 8 * i
x := a + b
j := j+1
A[t1] := j
if2 i!=1 goto etiq_endif2
A[t1] := j
etiq_endif2:
goto etiq_while
etiq_endwhile:
...
Figura 3.19 - Ejemplo de código intermedio
La división en bloques básicos del ejemplo anterior es la siguiente:
i := 0
j := 0
etiq_while:
i := i + 2
t1 := 8 * i
x := a + b
j := j+1
A[t1] := j
if2 i!=1 goto etiq_endif2
A[t1] := j
etiq_endif2:
goto etiq_while
etiq_endwhile:
...
Figura 3.20 - División en bloques básicos del ejemplo de la Figura 3.19

En este ejemplo se pueden realizar diversas optimizaciones que darían como resultado
el siguiente código:
...
i := 0
j := 0
x := a + b
t1 := 0
etiq_while:
t1 := t1 + 16
j := j+1
A[t1] := j
goto if
etiq_endwhile:
...
Figura 3.21 - Código de la Figura 3.19 optimizado
A continuación comentaremos cuáles son las optimizaciones realizadas sin entrar en el

detalle de las técnicas utilizadas.
Simplemente observando y entendiendo los cálculos de los bloques básicos, podemos

darnos cuenta de las siguientes cuestiones:
 La instrucción x := a + b, se recalcula en cada iteración del bucle, pero si nos

fijamos, no es necesario que esté dentro de él, ya que el cálculo es constante y
no depende de valores que varían en las iteraciones del bucle. Por lo tanto,
podemos mover la instrucción fuera del bucle.
 La alternativa if, no incorpora ningún código adicional o diferente al que puede

ser ejecutado al no entrar en la alternativa. De hecho, es el mismo código el que
hay dentro de la alternativa que fuera, por lo tanto, podemos eliminar
directamente el if. Esto se puede hacer debido a que no se lleva a cabo ninguna
acción adicional en el cuerpo del if y además, el destino del salto se encuentra
justo después de tampoco haber realizado ninguna acción.
 Finalmente, las instrucciones i := i + 2 y t1 := 8 *i pueden ser

reagrupadas en un único cálculo de la forma: t1 := 0 y t1 := t1 + 16. Esta
modificación puede llevarse a cabo suponiendo que el código después de la
etiqueta etiq_endwhile: no utiliza el valor de la variable i. Si no fuera el
mismo valor habría que mantener el valor de i. Con esta optimización
conseguimos cambiar un producto por una operación de suma, la cual es mucho
menos costosa.

Comentar de nuevo que, a pesar de que el tema de la optimización de código intermedio

es mucho más amplio, no se profundizará más en él debido a que no ha sido el propósito
de este proyecto.
3.3. Generación de Código Objeto

Esta fase y la siguiente que se explicará pertenecen a la etapa de Back-end,
siendo éstas dependientes de la arquitectura.
Durante la fase de Generación de Código Objeto, se traduce el código intermedio

optimizado a código objeto. En nuestro caso, la traducción será a lenguaje ensamblador
y se utilizará un compilador ya existente para traducirlo al código objeto final.
Esta fase es totalmente dependiente de la arquitectura sobre la que se vaya a ejecutar el

programa fuente, por lo tanto, deberemos tener una traducción para cada tipo de
plataforma sobre la que queramos ejecutar las aplicaciones.
En nuestro caso se ha optado por la generación de código ensamblador IA-32, debido a

que es el más habitual en la mayoría de arquitecturas Intel. En el Capítulo 6, se
profundizará en aspectos más específicos de este código, donde se explicaran sus
características.
La figura inferior simplemente muestra, a modo de ejemplo, parte de un programa en

código ensamblador IA-32.
movl $3, -4(%ebp)

leal -12(%ebp), %eax
movl $0 , %edx
addl %eax, %edx
movl $4, %eax
movl %eax, 0(%edx)
movl -4(%ebp), %eax
movl $4, %edx
imull %edx , %eax
movl %eax, %ecx
Figura 3.22 - Ejemplo de programación IA-32
La traducción a IA-32 presentaba varias alternativas:
 Traducción a partir del grafo de control de flujo. En este caso se trabaja con
cada bloque básico por separado. Se realiza la traducción para cada uno de los
bloques. A continuación, se une todo el código generado formando el programa
completo.

La principal ventaja que presenta esta alternativa es la optimización del uso de

los registros del procesador, ya que cada bloque básico dispone de todos los
registros, liberando los que no necesita. Esta opción se basa en el
reaprovechamiento de los registros. Precisamente, debido a este
reaprovechamiento de los registros, y al hecho de que el dato de un bloque
básico no sea necesario en otros, obliga a establecer mecanismos para el traspaso
de datos, lo cual hace de esta alternativa una opción complicada de implementar.
 Traducción a nivel de procedimientos o funciones. Esta opción no contempla la

división en bloques básicos y por tanto, no permite gestionar de forma tan
óptima los registros como la anterior, pero a cambio, ofrece una mayor facilidad
de implementación. Esta solución se fundamenta en el hecho de que los datos
asignados a un registro no cambiarán durante todo ese ámbito.
Para el desarrollo de este proyecto se ha optado por la segunda opción debido a que ésta
ya ofrece unos buenos resultados en términos de optimización.
Como ya se ha comentado, en el capítulo 6 se explicará en detalle el proceso de

traducción a IA-32.
3.4. Optimización de Código Objeto

Finalmente, pasamos a realizar la optimización del código objeto. Esta es la
última fase del compilador.
En este caso sí que se trata de una optimización dependiente de la arquitectura, ya que

estamos considerando aspectos propios de cada plataforma.
Por ejemplo, la sustitución de una determinada instrucción por otra más eficiente puede
ser algo concreto de una cierta arquitectura y cierto lenguaje ensamblador.
Otra de las optimizaciones más importantes son las realizadas con los registros. Siempre
se debe intentar llevar a registros físicos la información para que sean accesibles de una
forma más rápida.

Capítulo 4. Herramientas de Desarrollo de un Compilador
4. Herramientas de Desarrollo de un
Compilador
Hoy en día existen diferentes herramientas que ayudan con el desarrollo de un
compilador. Estas herramientas facilitan el trabajo del programador además de reducir
el tiempo de implementación. También permiten detectar errores de programación a la
hora de desarrollar las diferentes etapas del compilador.
Las herramientas existentes más habituales son, según clasificación en [1]:
 Scanner Generators. Se generan analizadores léxicos a partir de expresiones

regulares. El analizador léxico acaba siendo un programa que controla un
conjunto de DFAs, donde cada DFA se corresponde con una de las expresiones
regulares.
 Parser Generators. Estas herramientas generan automáticamente analizadores

sintácticos a partir de una gramática especificada por el programador. Antes era
una de las partes más difíciles de implementar debido a la complejidad de los
algoritmos necesarios para realizar el Parsing y generar los AST.
 Tree Parser Generators. Generan un conjunto de rutinas que permiten recorrer

los ASTs realizando determinadas tareas durante el recorrido.
o Syntax-directed Type Checking Engines. Se encarga de realizar el

Análisis Semántico del AST de entrada.
o Syntax-directed Translation Engines. Se basa en la idea de que a cada

nodo del árbol se le asigna una traducción, de manera que la traducción
de un nodo concreto del árbol se construye a partir de las traducciones de
sus nodos hijos. Estas herramientas se encargan de llevar a cabo la etapa
de generación de código intermedio.
 Data-flow Engines. Se encargan de captar información sobre el flujo de datos

para realizar una correcta optimización del código intermedio.
 Automatic Code Generators. A partir de unas reglas especificadas que indican

cuál es la traducción de cada sentencia de código intermedio a código máquina,
se genera el código máquina para la plataforma que se desea. Se basan en
plantillas de traducción, donde se sustituye directamente el código intermedio
por lo que indique su plantilla correspondiente.

4.1. ANTLR Parsing

La herramienta de desarrollo utilizada ha sido ANTLR v3. En previas
implementaciones de compiladores para el lenguaje CL, también se había usado
ANTLR en versiones más antiguas, también conocidas como PCCTS.
ANTLR (ANother Tool for Language Recognition) es una herramienta de lenguaje que
proporciona un framework para la construcción de reconocedores, intérpretes,
compiladores y traductores a partir de descripciones gramaticales que contienen
acciones en varios lenguajes. Además, la nueva versión dispone de un entorno gráfico
llamado ANTLRWorks que permite la definición de gramáticas de manera más fácil
para el usuario incluso cuando éste no es experto en el diseño de gramáticas y lenguajes
[5].
ANTLR se encarga de generar Scanners, Parsers y Tree Parsers automatizando la

construcción de reconocedores de lenguaje. A partir de una descripción formal del
lenguaje, ANTLR genera un conjunto de rutinas que determinan si una entrada forma
parte de ese lenguaje tanto a nivel léxico como sintáctico.
ANTLR genera Parsers de tipo recursivo descendente para el lenguaje deseado. Este
lenguaje puede ser tanto un lenguaje de programación como un formato de datos, pero
ANTLR no sabe nada acerca del lenguaje especificado en la gramática. También se
pueden incluir fragmentos de código que realicen determinadas tareas durante el
proceso de reconocimiento. ANTLR permite anotar la gramática con operadores de
forma que el usuario describe como quiere que sea el AST que espera que se construya.
Así pues, como hemos visto, la función principal de ANTLR es facilitar el trabajo al
programador, automatizando aquellas tareas más complicadas que forman parte del
proceso de reconocimiento a nivel léxico y sintáctico de un lenguaje.
ANTLR permite generar código en C, Java, Python, C#, Objective-C y otros que
actualmente están en desarrollo como por ejemplo, C++.
4.1.1. Estructura de ANTLR

A partir de una gramática combinada G donde se especifican tanto los tokens
como la gramática propiamente dicha en un mismo fichero G.g, ANTLR genera un
analizador formado por los siguientes archivos [2]:
 GLexer.java. Contiene el Lexer generado a partir del fichero G.g
 GParser.java. Contiene el Parser generado por la gramática.
 G.tokens. Contiene una lista de los tokens de la gramática.

Donde el nombre de cada archivo indica el rol de ese mismo archivo. Y la extensión
java indica el código en que se está generando el analizador.
Una vez tenemos creados estos ficheros ya podemos compilarlo y ejecutarlo para
comprobar la corrección de nuestro código fuente.
Como podemos apreciar, usar herramientas como ANTLR nos facilita el trabajo puesto
que simplemente especificando una gramática y un conjunto de tokens obtenemos un
Parser y Lexer, en lugar de tener que escribir nosotros estos programas.
4.1.2. Gramáticas en ANTLR
4.1.2.1. Sintaxis de las gramáticas
El nombre de los tokens siempre empieza con mayúscula. Las reglas sintácticas
o producciones de la gramática comienzan con minúsculas.
Para referirnos a los literales1 deberemos hacerlo siempre con tal literal entre comillas
simples, de la forma: „literal‟.
Las acciones incorporadas dentro de una regla gramatical se escriben en el lenguaje en

el que ANTLR generará el analizador. Estas acciones serán directamente trasladadas al
código del analizador.
4.1.2.2. Reglas
Como ya se ha comentado en el capítulo 2, las gramáticas están formadas por un

conjunto de reglas o producciones.
Las gramáticas pueden definirse utilizando diferentes notaciones. Las gramáticas con
notación BNF se especifican mediante un conjunto de reglas de la forma:
a → x | y | z
Figura 4.1 - Reglas notación BNF
ANTLR soporta otro tipo de gramáticas, las EBNF (Extended Backus–Naur Form).
Éstas permiten definir cualquier expresión regular a la derecha de la regla. Algunos
ejemplos de partes derechas de reglas especificadas con notación EBNF se muestran en
las siguientes figuras [2]:
1
Los literales son tokens cuya expresión regular asociada solo contiene esa palabra

(«x»|«y»|«z»). La entrada se corresponde

con una de las tres opciones.
x? x es un elemento opcional
(«x»|«y»|«z»)? La entrada se acepta si se

corresponde con alguna de las tres
opciones
x* La entrada se corresponde con el

elemento x cero o más veces
(«x»|«y»|«z»)* La entrada se corresponde

con una de las opciones cero o más veces
x+ La entrada se corresponde con el

elemento x una o más veces

(«x»|«y»|«z»)+ La entrada se corresponde

con una de las opciones una o más veces
Ahora veamos parte de una gramática con notación EBNF donde se aplica lo
anteriormente comentado.
l_instrs
: ( instr )*
;
instr
: left_expr ASSIG expr
| IF^ expr THEN! l_instrs ( ELSE! l_instrs )? ENDIF!
| WHILE^ expr DO! l_instrs ENDWHILE!
| READ^ LEFT_PAR! left_expr RIGHT_PAR!
| WRITE^ LEFT_PAR! ( expr | STRING_CONST ) RIGHT_PAR!
| NEW^ LEFT_PAR! left_expr RIGHT_PAR!
| FREE^ LEFT_PAR! expr RIGHT_PAR!
| WRITELN^ LEFT_PAR! ( expr | STRING_CONST ) RIGHT_PAR!
| IDENT LEFT_PAR actual_params RIGHT_PAR
;
Figura 4.2 - Gramática con notación EBNF
4.1.3. Principales características

ANTLR v3 introduce nuevas funcionalidades que facilitan mucho más el trabajo
del programador, ya que por ejemplo, ya no es necesario que el programador realice la
factorización. Además, permite controlar más la creación del analizador pudiéndose
personalizar a las necesidades de cada caso.
La novedad más importante es el concepto del Parsing LL(*), junto con el uso de los
StringTemplantes de cara a la generación de código. Muchas de las funcionalidades
específicas se activan en el propio fichero donde se describe la gramática, dentro de un
determinado bloque.

4.1.3.1. Parsing LL(*)
Como ya se ha comentado en el capítulo 2, existen analizadores descendentes LL(1),

LL(k) y LL(*). Pero veamos ahora el motivo de la necesidad de éstos dos últimos y por
qué en muchas ocasiones no basta con un token de lookahead para realizar el análisis.
Veamos un ejemplo sobre el lenguaje que nos concierne, CL:
expr_simple: INT_CONST
| NULL
| TRUE
| FALSE
| IDENT DOT IDENT
| IDENT LEFT_BRKT expr RIGHT_BRKT
.....
;
Figura 4.3 - Ejemplo de gramática en lenguaje CL
Para la regla anterior existen dos alternativas que comienzan con el mismo token
(IDENT) y que por lo tanto, se deberían de factorizar. Una vez factorizada, la regla
queda de la siguiente forma:
expr_simple: INT_CONST
| NULL
| TRUE
| FALSE
| IDENT (DOT IDENT | LEFT_BRKT expr RIGHT_BRKT)
.....
;
Figura 4.4 - Gramática de la Figura 4.3 factorizada
Como podemos observar, si no se realiza la factorización nos encontraríamos con una

gramática LL(k) donde k = 2, ya que serían necesarios dos tokens de lookahead para
poder diferenciar entre las dos alternativas con prefijo común.
La factorización es la técnica que resuelve las ambigüedades en el Parsing LL(k), pero

también esto da lugar a gramáticas menos legibles. Más aún podemos imaginar esta
situación para aquellas gramáticas que definen lenguajes más complejos como podrían
ser JAVA o C++ y que seguramente tendrán código incorporado en las diferentes
producciones.

El Parsing LL(*) es una de las principales características que ahora pasa a formar parte
del comportamiento por defecto de ANTLR. En esta nueva versión, por defecto,
ANTLR v3 trabaja con un número indeterminado y no limitado de tokens de lookahead.
Si se quiere deshabilitar esta opción, simplemente hay que indicar que la opción k
(haciendo referencia al ya comentado token de lookahead) pase a ser un número entero
mayor que 0. De esta manera estaremos limitando el Análisis Sintáctico al clásico
LL(k).
Cabe destacar el hecho de que el Parsing LL(*) no modifica la estrategia de Parsing

aplicada, sino que se trata de mejorar la capacidad predictiva del Parser para la toma de
decisiones ante disyuntivas.
La creación de una gramática implica la realización de una especificación para el

analizador sintáctico, además de conformar la estrategia de Parsing. Cuanto más
potente es la estrategia de Parsing, mayor es el número de gramáticas que puede aceptar
el analizador.
Existen estrategias de Parsing, como las LR, que permiten reconocer un mayor número
de gramáticas, pero en cambio, entre sus características están las de ser más
complicadas de entender y desarrollar.
Los analizadores descendentes que genera ANTLR v3 son más intuitivos y fáciles de
comprender, aunque a veces es necesario realizar modificaciones sobre la gramática
definida inicialmente como por ejemplo, la factorización izquierda de sus reglas.
Aunque herramientas como, por ejemplo ANTLRWorks la realizan automáticamente.
4.1.3.1.1. Por qué se necesita LL(*)
Consideremos la siguiente gramática:
method: type ID '(' args ')' ';'

| type ID '(' args ')' '{' body '}';
type: 'void' | 'int' ;
args: arg (',' arg)* ;
arg: 'int' ID ;
body: ... ;
Figura 4.5 - Ejemplo gramática LL(*)
Esta gramática no es LL(k). Si observamos la producción method podemos ver que las
dos alternativas posibles tienen un prefijo común:

method: type ID '(' args ')' ';'

| type ID '(' args ')' '{' body '}';
Figura 4.6 - Ejemplo gramática LL(*) - Elementos comunes
Estas partes comunes impiden tomar una decisión al Parser con un número de tokens de
lookahead finito, ya que no sabemos cuántos argumentos tendrá el método (args) y por
tanto, no podemos decidir cuál de las dos alternativas de la producción nos llevará a
aceptar la entrada.
No podemos fijar una k que nos permita diferenciar entre el “;” de la primera
alternativa y el “{“ de la segunda alternativa de la regla. Pero, esta arbitrariedad
realmente desaparece en tiempo de ejecución, por lo tanto, la k es conocida sólo en ese
momento.
La forma de resolver este conflicto sería factorizar por la izquierda de la siguiente

forma:
method: type ID '(' args ')' (';' | '{' body '}' );
Figura 4.7 - Factorización de la Figura 4.6
Veamos a continuación un ejemplo de este problema para la gramática de CL:
instr: left_expr ASSIG expr;

...
func_call: IDENT LEFT_PAR actual_params RIGHT_PAR ;
...
left_expr: IDENT ( DOT IDENT

| LEFT_BRKT expr RIGHT_BRKT
| CIRCUMFLEX )*
| func_call ( DOT IDENT
| LEFT_BRKT expr RIGHT_BRKT
| CIRCUMFLEX )*;
Figura 4.8 - Ejemplo factorización en gramática de CL
El ejemplo anterior ilustra el problema con el que se encuentra un Parser a la hora de

diferenciar entre una entrada del tipo F(a,b,c,)^ := x y F(a,b,c). Dado que ambas

instrucciones tienen un prefijo común, el Parser necesita un número indeterminado e

ilimitado de tokens para poder distinguir entre si lo que va a continuación es el símbolo
“^” o nada, en cuyos caso se trataría de una asignación o bien de la llamada a una
función. En el ejemplo que se ha presentado es más sencillo, puesto que con cuatro
tokens de lookahead sería suficiente para distinguir entre las dos alternativas, pero lo
cierto es que una función puede tener muchos más parámetros, dificultando aún más la
decisión y de ahí que sea necesario un Parser que trabaje con un número indeterminado
e ilimitado de tokens.
4.1.3.1.2. Decisiones LL(*)
Hemos comentado qué problemas ayuda a solventar el Parsing LL(*), pero

veamos ahora en qué se basan las decisiones del algoritmo de Parsing LL(*).
Supongamos el siguiente ejemplo de regla gramatical:
expr : ID '[' CONST ']'

| ID '.' ID ;
Figura 4.9 - Regla gramatical para reconocer una expresión
Esta gramática es LL(k). Dado que el símbolo inicial de las dos alternativas es el
mismo, podemos apreciar que necesitaríamos una k = 2 para poder determinar cuál es la
alternativa correcta.
El código que hubieran generado versiones anteriores de ANTLR sería de la forma:
void stat() {
if ( LA(1)==ID&&LA(2)==EQUALS ) { // PREDICT
match(ID); // MATCH
match(EQUALS);
expr();
}
else if ( LA(1)==ID&&LA(2)==COLON ) { // PREDICT
match(ID); // MATCH
match(COLON);
stat();
}
else «error»;
}
Figura 4.10 - Código generado por versiones anteriores de ANTLR para la Figura 4.9

Si nos paramos a pensar, veremos, que realmente la decisión no depende del token
IDENT, sino que depende del segundo token de lookahead.
Otro algoritmo posible, esta vez fijándonos únicamente en aquél token decisivo sería:
void stat() {
int alt=0;
if ( LA(1)==ID ) {
if ( LA(2)==EQUALS ) alt=1;
else if ( LA(2)==COLON ) alt=2;
}
// MATCH PREDICTED ALTERNATIVE
switch (alt) {
case 1 : // match alternative 1
match(ID);
match(EQUALS);
expr();
break;
case 2 : // match alternative 2
match(ID);
match(COLON);
stat();
break;
default : «error»;
}
}
Figura 4.11 - Código generado por ANTLR para reconocer la Figura 4.9
En este caso, el código ya está más enfocado hacia lo que realmente es la toma de
decisiones. Como podemos ver, primero se toma cierta información acerca de los tokens
de la entrada y, una vez se tiene la información, se pasa a ejecutar la decisión que
corresponda.
El DFA que corresponde a la regla es el siguiente:
Figura 4.12 - DFA para la gramática de la Figura 4.9

Este DFA codifica la secuencia de tokens de lookahead donde los estados s2 y s3 son
estados aceptadores para cada una de las alternativas.
LL(*) extiende LL(k) permitiendo DFAs cíclicos2 que permiten escanear la entrada de
forma arbitraria hasta que encuentran la k que permite diferenciar entre una alternativa y
otra.
Veamos un ejemplo sencillo de regla LL(*) con su correspondiente DFA cíclico.
def : modifier* classDef

| modifier* interfaceDef;
Figura 4.13 - Regla LL(*)
Figura 4.14 - DFA para la regla de la Figura 4.13
En un programa concreto, podemos tener un número indeterminado de modificadores

que, a pesar que a nivel teórico es infinito, en momento de ejecución pasa a ser un
número finito, pero que simplemente a priori desconocemos.
La decisión LL(*) se basa en buscar la k mínima que nos permite tomar la decisión
correcta. Como se puede observar la diferencia con el LL(k) reside en que no tenemos
nosotros la responsabilidad de especificar el número de tokens de lookahead necesarios.
Una vez se conoce cuál es la k necesaria para la decisión, ANTLR trabaja igual que en
el LL(k). Por lo tanto, ANTLR sólo usa el DFA para distinguir entre las diferentes
alternativas dentro de una determinada producción y no para toda la gramática.
El código de Parsing correspondiente al anterior ejemplo sería:
2
Por DFA cíclico nos referimos a que puede contener ciclos en alguno de sus caminos

void def() {
int alt=0;
while (LA(1) in modifier) consume();
if ( LA(1)==CLASS ) alt=1;
else if ( LA(1)==INTERFACE ) alt=2;
switch (alt) {
case 1 : ...
case 2 : ...
default : error;
}
}
Figura 4.15 - Código de Parsing para la Figura 4.13
Podemos ver como el código generado traduce a la perfección el DFA cíclico mostrado.
Permaneciendo en un bucle hasta que aparece el token diferenciador de las alternativas.
Podemos decir que una decisión es LL(*) si se cumplen las siguientes condiciones:
 Existe un DFA que reconoce el lenguaje generado por los tokens de lookahead.
 No existen estados no alcanzables en el DFA.
 No existen estados que no lleven a un estado de aceptación en el DFA.
 Existe como mínimo un estado de aceptación para cada una de las alternativas
de la gramática.
Finalmente, diremos que una gramática es LL(*) si todas las decisiones que contiene
son LL(*).
Podríamos pensar que esta forma de actuar es similar al backtracking, pero en realidad
no son iguales. El backtracking tiene un coste mucho más elevado puesto que seguimos
avanzando y realizando acciones que, en el caso que el camino finalmente no sea el
correcto, hay que deshacer.
La predicción LL(*) lo que realmente hace es explorar antes de tomar ninguna decisión
sin realizar ninguna acción y, una vez dispone de información suficiente, entonces y
sólo entonces actúa realizando las acciones pertinentes en ese momento.
4.1.3.1.3. Decisiones Incompatibles
Existen tipos de decisiones que ANTLR no puede resolver [2]:
 Ambigüedad gramatical. El indeterminismo se produce cuando una entrada

puede corresponderse con más de una alternativa dentro de una misma

producción y por lo tanto, nos encontramos con una decisión ambigua. A pesar
de ello, en este caso ANTLR sí que es capaz de generar un DFA.
La mayoría de los indeterminismos aparecen por ambigüedades inherentes al

lenguaje que definen.
Uno de los ejemplos más claros de ambigüedad es:
stat: 'if' expr 'then' stat ('else' stat)?

| ID '=' expr ';'
;
Figura 4.16 - Ejemplo de gramática ambigua
Con una entrada del tipo: if a then b=2 if b then b=3 else b=1 no
seríamos capaces de determinar a qué if se corresponde el else.
Prácticamente en todos los casos la solución pasa por el uso de predicados

semánticos y sintácticos o bien, como en este ejemplo, por determinar si en la
decisión se debe tener un comportamiento voraz, el que se vincularía al último
if.
 Recursividad izquierda. Esto ocurre porque el lenguaje de lookahead no es

regular.
Un ejemplo de este tipo de gramáticas podría ser:
expr: expr ´+‟ IDENT

| IDENT;
Figura 4.17 - Ejemplo de recursividad izquierda
Con esta regla sólo se puede generar la secuencia: expr „+‟ IDENT ‟+‟
IDENT... entrando en un bucle infinito que el algoritmo de Parsing no sabría
cómo resolver.
La solución a la recursividad izquierda pasa por corregirla variando el orden de

los elementos de la regla y transformándola en recursividad derecha.
expr: IDENT „+‟ expr

| IDENT
;
Figura 4.18 - Solución a la recursividad izquierda de la Figura 4.17

También se puede utilizar la notación EBNF para definir la gramática sin

cambiar la asociatividad izquierda del operador de suma.
expr: IDENT („+‟ IDENT)* ;
Figura 4.19 - Solución a la recursividad izquierda de la Figura 4.17 usando EBNF
Si bien es cierto que la recursividad izquierda es aceptada por otro tipo de

Parsers, ANTLR no la permite y es por ello que hay que ir con cuidado a la hora
de la construcción de la gramática.
 Decisiones no LL(*). Estas son decisiones en las que el programador no deja

claro explícitamente que se desea una recursividad y ANTLR no sabe si la
recursividad es deseada. Un ejemplo de este tipo de gramáticas es:
s : label ID '=' expr

| label 'return' expr
;
label: ID ':' label
|
;
Figura 4.20 - Ejemplo de gramática con decisión no LL(*)
Como se puede observar, la regla label da lugar a un DFA con múltiple

recursividad y sin llegar a un fin. La solución pasa por indicar de manera
explícita la recursividad:
label: (ID ':' )* ;
Figura 4.21 - Solución a la decisión no LL(*) de la Figura 4.20
4.1.3.2. Predicados Sintácticos y Semánticos
Los predicados son una herramienta que ANTLR pone a disposición del
programador para que éste especifique al Parser cómo resolver problemas de
reconocimiento. Nos sirven para solventar, por ejemplo, problemas de ambigüedad que
el LL(*) Parsing no podría solucionar.

Los predicados se encargan de modificar la forma en la que se realiza el Parsing a

medida que reciben información durante el reconocimiento. Son sencillos de utilizar y
otorgan mayor claridad al código puesto que evitan la reescritura de reglas para la
solución de algunos problemas.
Los Parsers LL(*) con predicados permiten el reconocimiento de prácticamente

cualquier CFG.
4.1.3.2.1. Predicados Semánticos
Los predicados semánticos son condiciones booleanas que si se cumplen, dan

como válida la alternativa de una regla. Las comprobaciones son siempre a nivel
semántico. Un ejemplo de comprobación semántica sería la necesidad de saber que un
mismo token se repite única y exclusivamente n veces.
En general se pueden escribir en cualquier lugar de la parte derecha de una regla.

Veamos un ejemplo de uso de ellos:
: ^( ASSIG
{ $instr::type = $ASSIG.getASTChild(0).getTypeTree();
$instr::isRef = $ASSIG.getASTChild(1).getReferenciable();
size = typeSize($instr::type)
}
...
|{!($instr::type.isTypeBasicOrPointer()) && $instr::isRef}?

le1=expr_address[temp] le2=expr_address[temp+2]
...
Figura 4.22 - Ejemplo de regla con predicado semántico
La figura superior muestra resaltado el predicado semántico. En este caso se está

comprobando si en una asignación el lado izquierdo de ella es un tipo básico o puntero
y además, si el lado derecho de la asignación es referenciable. Si se cumplen ambas
condiciones, el compilador sabe que se encuentra en la situación de tener que calcular la
dirección para ambos lados de la asignación y además, se llevarán a cabo ciertas
acciones que no se detallan en el ejemplo.
En la mayoría de ocasiones, los predicados semánticos necesitan información

almacenada anteriormente en una Tabla de Símbolos para poder consultar.
Éstos se usan principalmente para resolver los problemas con gramáticas no-LL(*).
Imaginemos que queremos reconocer aquellas palabras formadas por cadenas de B‟s.

a: B B B
| B B
| B
;
Figura 4.23 - Gramática que reconoce cadenas de B
Si estas cadenas son de un número pequeño de B‟s como el del ejemplo, la regla no
supone ningún problema. Supongo ahora que tuviéramos que reconocer todas las
cadenas formadas por, como máximo cien B’s. Como podemos imaginar, esta solución
no es viable para el programador. La solución pasa por incorporar código en la regla
como el siguiente:
a: ( symbol+= B )+ {if ( $symbol.size() > 100 ) «error»;}

;
Figura 4.24 - Gramática para reconocer cadenas de hasta cien B’s
O bien, por la opción que ofrece ANTLR de validación de predicados semánticos

teniendo como resultado:
a: ( symbol+ = B )+ {$symbol.size() <= 100}?

;
Figura 4.25 - Gramática de ANTLR para reconocer cadenas de hasta cien B’s
4.1.3.2.2. Predicados Sintácticos
Los predicados sintácticos trabajan como los predicados semánticos pero

especificando la validez sintáctica de una alternativa. Si el predicado sintáctico, es decir,
la condición se cumple, la alternativa es válida. Este tipo de predicados nos permite
disponer de un analizador sintáctico con backtracking, aunque hay que tener en cuenta
que no se realizan las acciones que se puedan encontrar por en medio, puesto que lo que
sí que no hará el algoritmo si ha de volver atrás es deshacer acciones.
La diferencia con los predicados semánticos es que los primeros hacen una lectura
previa de parte de la entrada intentando reconocerla mientras que los semánticos
evalúan condiciones booleanas.
La diferencia entre el uso de los predicados sintácticos y el Parsing LL(*) reside en que
son mucho más potentes que los DFAs creados por este último para la toma de

decisiones en alternativas; y por ello, permiten solucionar problemas más complejos

sobre las estructuras de las sentencias.
Los predicados sintácticos en realidad implementan una CFG que trabaja con pila y por
ello, permite reconocer estructuras anidadas y de árbol que los DFAs no pueden. Es
decir, que ante un predicado sintáctico, ANTLR genera un Parser usado únicamente
para la toma de la decisión en cuestión. Una vez tomada esa decisión, se continúa el
análisis de la forma habitual.
Son especialmente útiles en dos situaciones:
 Si LL(*) no puede tratar con la gramática en la forma en que nosotros queremos

expresarla.
 Para especificar la prioridad entre dos alternativas ambiguas.
Veamos un ejemplo de este problema con nuestro lenguaje CL. CL permite

instrucciones del tipo:
 f( ).x = a , siendo f () una función que retorna un tipo struct.
 p( ), siendo p( ) un procedimiento
La regla instr inferior define el tipo de instrucciones que podemos encontrar en CL. Si
definimos la sintaxis de CL de manera natural tendríamos la siguiente regla:
instr: left_expr ASSIG^ expr (1)

| IDENT LEFT_PAR actual_params RIGHT_PAR (9)
left_expr: func_call ( dt=DOT^ IDENT

| lb=LEFT_BRKT^ expr RIGHT_BRKT!
| ACCESO PUNTERO);
func_call: IDENT LEFT_PAR actual_params RIGHT_PAR ;
Figura 4.26 - Regla instr en CL
El problema en este caso viene dado porque la regla left_expr contiene, entre otras, la
alternativa que veremos a continuación.

Si nos fijamos, se produce una ambigüedad puesto que podemos encontrar la siguiente
secuencia:
„ IDENT LEFT_PAR actual_params RIGHT_PAR ‟
Figura 4.27 - Fuente de ambigüedad para la gramática de la Figura 4.26
Esta secuencia se puede obtener por dos caminos diferentes, entrando por la alternativa
1 o 9 (resaltadas) de la regla instr. Y por lo tanto, no podemos diferenciar a priori
entre las entradas comentadas anteriormente: f( ).x = a y p( ), dado que las dos
tienen la misma estructura inicial.
Podríamos intentar una posible factorización, pero dado el nivel de complicación de ésta
y que perderíamos legibilidad del código, el uso de un predicado sintáctico es la mejor
opción para solucionar el problema.
Así pues, la regla instr queda definida de la forma:
instr: (left_expr ASSIG) => left_expr ASSIG^ expr

| IDENT LEFT_PAR actual_params RIGHT_PAR
Figura 4.28 - Regla instr con la ambigüedad resuelta
Donde tenemos el siguiente predicado sintáctico:
(left_expr ASSIG) => left_expr ASSIG^ expr
Figura 4.29 - Predicado sintáctico de la regla de la Figura 4.28
Este predicado indica a ANTLR de manera explícita cuándo debe escoger la alternativa
1. En este caso, cuando encuentre una left_expr seguida del token ASSIG sabe que esa
alternativa es la correcta. Si no fuera el caso debería seguir buscando en las otras
alternativas fuente del conflicto.

Los predicados sintácticos trabajan de la misma forma en que lo hace la opción de

backtrack que permite habilitar ANTLR dentro de una determinada regla, a pesar de que
durante el predicado sintáctico no se realiza ninguna acción para así no tener que
deshacerla durante el backtracking.
4.1.4. AST Construction

Como ya hemos comentado en el capítulo 2, una de las estructuras de datos más
importantes con las que trabajamos son los árboles AST. Los ASTs son una
representación interna del programa de entrada con la información de entrada necesaria
para las operaciones que deben realizar las siguientes fases del compilador. Esta
estructura tipo árbol es mucho más adecuada que una simple lista de tokens dado que un
árbol representa mucho mejor la estructura de la entrada, debido a la jerarquía del
lenguaje.
ANTLR permite decorar la gramática con anotaciones sobre cómo se debe construir el
AST. Hemos de tener en cuenta que cada regla produce un subárbol y que, la
producción inicial de la gramática genera el AST completo. Cada nodo del árbol
proviene de un token de la entrada, pero también es posible crear nodos del árbol que
representan tokens “ficticios3”.
Además de crear la estructura del árbol que deseemos, ANTLR también traslada al
usuario la decisión de cómo quiere que sean los nodos del árbol. Esto permite que poder
decidir qué información guardar en los nodos del árbol. Para ello, simplemente hay que
indicar mediante la opción ASTLabelType que el nodo sea de la clase nodo creada,
definida como una clase derivada de la clase base CommonTree.
ANTLR proporciona la clase CommonTree, la cual está formada por unos atributos
básicos que almacenan la información considerada necesaria para cada token y por
tanto, para cada nodo del árbol. A partir de CommonTree se puede definir una clase que
hereda sus atributos, pero además, permita almacenar otra información relevante para
determinados compiladores. Para el caso de CL, es interesante guardar la información
relativa al número de línea dentro del código donde se encuentra un token, saber si es
referenciable,...
Para que ANTLR dé como resultado un árbol necesita tener activada la opción output =
AST. De esta manera, si no se especifica ninguna anotación en la gramática, el Parser
creará un conjunto de ASTs donde cada uno contiene el correspondiente token de la
entrada, es decir, una lista plana de tokens.
3
Llamaremos nodos ficticios a aquellos que no provienen del Parser de la entrada.

Sin embargo, ANTLR permite el uso de operadores que alteren la creación del árbol
según nuestro criterio. La sintaxis de las reglas gramaticales se ven poco afectadas
puesto que, a priori, se trata de introducir los siguientes operadores: “^” y “!”.
 El operador “^” detrás de un token indica que ese token pasará a ser la nueva
raíz del subárbol de aquella regla.
 El operador “!” indica que ese token no se incorpora a la hora de formar el

árbol puesto que no contiene información relevante.
Veamos un ejemplo de aplicación en la gramática de nuestro lenguaje CL:
dec_block: PROCEDURE^ IDENT proc_header l_vars l_blocks

l_instrs ENDPROCEDURE!
| FUNCTION^ IDENT func_header l_vars l_blocks
l_instrs instr_return ENDFUNCTION!
;
Figura 4.30 - Ejemplo de aplicación de los operadores de modificación en ANTLR
Como podemos observar, en este caso, la regla dec_block define los bloques que
podemos encontrar en un programa CL: funciones y procedimientos. Para cada una de
estas alternativas, ANTLR construirá un subárbol que tendrá como raíz el token
PROCEDURE o FUNCTION. Sus hijos serán el token IDENT y los subárboles resultantes de
las llamadas al resto de reglas gramaticales.
Se puede apreciar que los tokens ENDPROCEDURE y ENDFUNCTION serán despreciados en

la generación del árbol, ya que van seguidos del símbolo “!”.
También podemos especificar en la gramática cómo queremos construir los ASTs

utilizando una notación similar a las reglas de reescritura. Esta opción es preferible a la
del uso de operadores puesto que es más legible y flexible.
La reescritura de reglas consiste en especificar la estructura gramatical y de dos

dimensiones del árbol que queremos construir. ANTLR permite introducir estas
indicaciones para cada alternativa en cada regla después del símbolo “->”.
La notación utilizada es la siguiente:

regla: «alternativa1 » -> « AST a construir a partir de alt1 »

| «alternativa2 » -> « AST a construir a partir de alt2 »
. . .
. . .
| «alternativaN » -> « AST a construir a partir de altN »
;
Figura 4.31 - Reescritura de reglas en ANTLR
Veamos un ejemplo de aplicación de esta forma de detallar la creación de árboles para

nuestro lenguaje CL, donde introducimos en la raíz del AST el nodo “ficticio”
ListOfInstrs:
l_instrs: ( instr )* -> ^( ListOfInstrs (instr)*) ;
Figura 4.32 - Ejemplo I de reescritura de reglas aplicado a CL
La regla l_instrs define que una lista de instrucciones se compone de cero o más
instrucciones. El símbolo “->” indica que a continuación vamos a detallar la creación
del árbol para esta regla.
La reescritura de las reglas permite adaptar la entrada al árbol resultante de la manera

que deseemos. Podemos hacer diferentes acciones:
 Eliminar símbolos innecesarios. En ocasiones, a la hora de reconocer el

lenguaje, nos encontramos con símbolos como comas, puntos y comas....que en
realidad no deben ser incorporados al AST. Con la reescritura de reglas podemos
obviar todos estos elementos innecesarios. Veamos un ejemplo de ello en CL:
l_formal_params: LEFT_PAR ( l_dec_params )? RIGHT_PAR

-> ^(ListOfFormalParams (l_dec_params)
;
Figura 4.33 - Ejemplo II de reescritura de regla en CL
La regla l_formal_params define la sintaxis de los parámetros formales de una

función o procedimiento. Como podemos ver, hemos eliminado los tokens
LEFT_PAR y RIGHT_PAR puesto que no nos aportan ningún tipo de información.
La forma de eliminarlos es simplemente no mencionarlos en la reescritura de la
regla.

También nos podemos preguntar sobre el token ListOfFormalParams. Éste es

un nodo “ficticio” que trataremos a continuación como otra de las opciones que
ofrece ANTLR para la creación de árboles.
 Reordenación de elementos. Al igual que en el caso anterior, en ocasiones la

interpretación humana no es la mejor para la forma para computar. La reescritura
permite la reordenación de tokens. Veamos un ejemplo muy común sobre la
declaración de variables:
dec_var : type ':' ID -> ID type ;
Figura 4.34 - Ejemplo de reordenación de elementos en una regla
Supongamos el lenguaje de programación C. A la hora de declarar variables, lo

hacemos de la forma: int a; pero quizá, a la hora de guardar la información en
el árbol nos puede interesar guardarla al revés.
 Indicar la raíz de un subárbol. Reescribir la regla de la forma ^(....) permite

indicar cuál es la raíz del subárbol. Esto es lo que permite dotar de estructura
bidimensional a los ASTs.
expr_unary: NOT expr_unary -> ^( NOT expr_unary )

| m=MINUS expr_unary -> ^( UnaryMinus[m]
expr_unary )
| expr_simple
;
Figura 4.35 - Ejemplo de raíz de un árbol en CL
La regla expr_unary define las expresiones con operadores unarios que

podemos encontrar en nuestro lenguaje CL. En el caso de la alternativa NOT el
árbol creado tiene como raíz el token NOT con un hijo que es el subárbol
resultante de la llamada, de nuevo, a la regla expr_unary.
En esta misma regla también podemos ver como ANTLR permite definir utilizar
el token “ficticio” UnaryMinus como raíz del árbol en la segunda alternativa,
pero incorporando todo el resto de información del token “real” MINUS en dicho
nodo.
 Creación de nodos ficticios. En ocasiones, puede ser útil añadir nodos ficticios
para crear una estructura de árbol más legible. Por ejemplo, en el caso de CL
ayuda a comprender la declaración de variables, lista de instrucciones, lista de
bloques....

Para que un nodo sea ficticio, no debe de tener ninguna referencia en el lado
izquierdo del símbolo “->” , aunque sí que debe estar declarado como token
junto con el resto de tokens de la gramática.
Veamos un ejemplo claro de aplicación para CL:
l_vars :
( VARS l_dec_vars ENDVARS)? -> ^( ListOfVars
(l_dec_vars)? )
;
l_dec_vars: ( dec_var )*
;
Figura 4.36 - Ejemplo de creación de nodos imaginarios en CL
La regla l_vars define la declaración de variables de un programa. En la

reescritura de la regla se ha añadido un nodo ficticio ListOfVars que será la raíz
del subárbol producido por la regla y que servirá para agrupar todas las
declaraciones de variables en un mismo subárbol.
 Duplicar nodos y árboles. A veces puede ser necesario duplicar un subárbol de

una regla. A pesar que nuestro lenguaje CL no lo permite, en lenguajes de
programación como C, podemos tener declaraciones del tipo: int a, b;
La correspondiente regla y subregla sería:
dec_var : 'int' ID (',' ID)* -> ^('int' ID)+ ;
Figura 4.37 - Ejemplo de duplicación de árbol en CL
Como podemos ver, el resultado para el ejemplo serán dos árboles, donde int
es la raíz de ambos y sus hijos respectivos son a y b.
 Recolección de elementos para crear un único árbol. Siguiendo con el ejemplo

anterior, podemos desear que, en lugar de tener dos árboles por separado, tener
un único árbol de raíz int e hijos a y b.
dec_var : 'int' ID (',' ID)* -> ^('int' ID+) ;
Figura 4.38 - Ejemplo de recolección de elementos en CL
Tal y como hemos podido comprobar, en la reescritura de las reglas se utiliza notación
EBNF haciendo uso de los operadores “+”,”*” y “?” con la semántica habitual.

4.2. ANTLR Tree Parsing

Una vez el Parser genera el AST, para poder realizar el Análisis Semántico y la
Generación de Código Intermedio, es necesario un algoritmo que recorra ese árbol.
Estos algoritmos reciben en nombre de Tree Walkers. Por lo tanto, durante la
implementación del compilador de CL será necesario implementar varios de estos
algoritmos.
Una extensión de los Tree Walkers son los Tree Parsers. Un Tree Parser es un
algoritmo que recorre un árbol a la vez que va realizando comprobaciones sobre su
estructura. Además, también es capaz de llevar a cabo acciones durante tal recorrido.
Los Tree Parsers pueden ser implementados manualmente, pero ANTLR proporciona
mecanismos para poder ser generados automáticamente, las Tree Grammars.
Una Tree Grammar es una gramática con reglas muy similares a las reglas de una
gramática standard, donde la parte derecha de las reglas especifica cómo debe ser la
estructura del subárbol a recorrer. De hecho, una de las facilidades que proporciona
ANTLR es que a partir de un Parser que genera un AST, se puede construir de manera
sencilla una Tree Grammar.
La notación usada para las Tree Grammars es la misma que para las gramáticas. Las
Tree Grammars se encargan de definir la estructura del AST generado por la etapa de
Parsing.
Como ya se ha comentado, en la definición de la Tree Grammar se puede incorporar

acciones a llevar a cabo durante el recorrido por los diferentes nodos del árbol. Para
realizar comprobaciones, extraer información, realizar cálculos... se insertan tales
acciones dentro de las Tree Rules, de forma similar a como se puede hacer en una
gramática convencional.
A partir de la Tree Grammar, ANTLR genera el Tree Parser que verificará si la

estructura del AST se corresponde con la definida en la Tree Grammar. Tal
comprobación se encarga de verificar que además de que los nodos sean los adecuados,
se cumpla la estructura bidimensional del árbol. En caso de no ser así, notifica al
usuario de los posibles errores.
ANTLR reduce el Tree Parsing al habitual Parsing de tokens, utilizando las mismas
estrategias de reconocimiento. Esto es posible puesto que ANTLR serializa los árboles
como una cadena de nodos de árbol donde se han insertado nodos “ficticios” UP y DOWN
que indican la estructura del árbol.
Los nodos DOWN indican cuando se baja un nivel en el árbol para visitar los hijos y el UP
indica cuando se acaba la lista de hijos.
Veamos el ejemplo de serialización de un AST.

Figura 4.39 - Ejemplo expresión a serializar
Su serialización como cadena de nodos de árbol es la siguiente:
+ DOWN 10 * DOWN 3 2 UP UP
Figura 4.40 - Serialización de la expresión de la Figura 4.40
A continuación veamos un ejemplo sencillo de construcción de una Tree Grammar a

partir de su correspondiente gramática. Supongamos la siguiente regla:
grammar G;
…
decl : 'int' ID ( ',' ID )* -> ^ ( 'int' ID+ ) ;
…
Figura 4.41 - Ejemplo de gramática para convertir en Tree Grammar
La parte de regla a la derecha del símbolo “->” es la reescritura de esa regla, indicando
cómo es el formato del AST para esa regla. Así pues, la Tree Grammar que contiene esa
Tree Rule es de la forma:
tree grammar G;
...
decl : ^ ( 'int' ID+ ) ;
…
Figura 4.42 - Tree Grammar de la Figura 4.41

Como se puede ver, la Tree Rule decl es simplemente la reescritura que ya existía en la
gramática de la Figura 4.41.
Cabe destacar el hecho que se debe indicar que una gramática es una Tree Grammar en
la primera línea del fichero donde se define con la sentencia “tree grammar
<nombre>;”.
Un ejemplo de algunas de las Tree Rules para la Tree Grammar de CL encargada del
Análisis Semántico es:
...
l_dec_types: ^( ListOfTypes ( dec_type )* );
dec_type : ^( i=IDENT t=type )

{
SymTab.search_returnret =
symTab.searchSymbolCurrScope($i.getText());
if (ret == null){
symTab.insertSymbol($i, SymTab.TYPENAME, t);
}
else{
errors.add_IdentAlreadyDeclared($i);
}
} ;
...
Figura 4.43 - Ejemplo de Tree Rule para CL
Las anteriores reglas definen la declaración de tipos por parte del usuario. Éstas
muestran como es el AST esperado y para la regla dec_type se puede observar cómo
se realizan acciones y comprobaciones durante el recorrido del árbol, que verifican que
el nombre de tipo no ha estado previamente declarado y lo inserta en la Tabla de
Símbolos.
Para aumentar la potencia a la hora de tomar decisiones, ANTLR permite incorporar

predicados semánticos en las Tree Grammars. De igual manera que para las gramáticas
se permite cambiar el número de tokens de lookahead, en las Tree Grammars los
predicados semánticos permite facilitar la toma decisiones respecto que alternativa
seguir.
La figura inferior muestra un ejemplo de predicado semántico en una de las reglas de la

Tree Grammar que implementa el Análisis Semántico. Aparecen resaltados los dos
predicados semánticos.

l_actual_params [TypeTree formal_params, Integer temp]

...
: ^( ListOfActualParams
(
( {formal_param.isValFormalParam()}? expr_value[temp]
| {formal_param.isRefFormalParam()}? expr_address[temp]
)
)*
);
Figura 4.44 - Ejemplo de predicado sintáctico en la Tree Grammar de CL
4.3. StringTemplates
Los StringTemplates son la nueva herramienta que proporciona ANTLR para
facilitar la emisión de código estructurado, trabajo que anteriormente se realizaba
mediante sentencias printf o cout.
StringTemplate es una librería que se compone principalmente de dos clases:

StringTemplate y StringTemplateGroup. Se puede crear directamente un template o
patrón de traducción de varias formas: directamente en el código del compilador,
cargándolo de un fichero o bien, cargar un fichero que contiene múltiples patrones,
siendo esta última la opción más habitual cuando hay un gran número de patrones
diferentes. El compilador hace uso de estos patrones utilizando una notación especial
con reglas de reescritura, que a continuación detallaremos y que es muy parecida a la
usada en el Parser para la construcción de los ASTs.
Los principales motivos para usar StringTemplate son (según consta en [2]):
 Mayor facilidad en el mantenimiento del código. El hecho de mantener

separado el modelo de datos y los cálculos de los patrones de traducción aporta
una mayor independencia.
 Mayor facilidad de lectura y escritura. Esto también viene propiciado por el

hecho de tener separadas las partes del código.
 Mayor facilidad para cambiar el lenguaje de traducción. De esta manera, el

compilador puede emitir traducciones en diferentes lenguajes.
 Aplicación del patrón de diseño de software Modelo-Vista-Controlador [6].
Debido a todo esto, podemos crear un traductor para múltiples lenguaje target
simplemente definiendo un fichero de StringTemplates para cada uno de ellos.

Podemos considerar los StringTemplates como strings con huecos que se van rellenando
con expresiones que son función de los atributos que reciben. La clase StringTemplate
contiene un método toString() que lo convierte en el texto correspondiente al
programa ya traducido, y que puede ser mostrado por pantalla.
Un StringTemplate puede contener texto, que puede ser directamente impreso, huecos
que podemos rellenar con strings o StringTemplates, y también se pueden utilizar
directivas, comprendidas entre los signos “<” y “>”, que permiten describir
StringTemplates complejos que contienen iteraciones, alternativas,...
El esquema básico de la definición de un patrón de traducción es la siguiente:
nombreRegla (param1, param2,..........., paramN) :: = <<

..................................................
>>
Figura 4.45 - Esquema de un patrón de traducción
Un ejemplo concreto de patrón de nuestro lenguaje CL es el siguiente:
writelnString(string) ::= <<

wris <string>
wrln
>>
Figura 4.46 - Ejemplo de patrón de la instrucción writeln de CL
La figura superior muestra uno de los ejemplos más sencillos de StringTemplates que
podemos encontrar. Éste se encarga de traducir una llamada a la función
writeln(param), la cual muestra por pantalla el contenido del parámetro “param”. El
patrón traduce esa llamada por dos nuevas instrucciones: wris <string>, seguida de
writeln. La directiva <string> indica que en esa posición se mostrará por pantalla
directamente el valor de ese parámetro del StringTemplate.
Veamos ahora un ejemplo de patrón más complejo donde se aprovecha toda la potencia
que permiten los StringTemplates:

procCall(ident, pushParams, computeSL, popParams) ::= <<

<pushParams:{<if(it.nuclear)> push
<it.text><else><it><\n> push t<it.temp><endif>};
separator="\n">
<if(computeSL.brotherCall)>
push static_link<else><computeSL><\n>
push t<computeSL.temp><endif>
call <ident>
pop
<popParams:{ pop}; separator="\n">
>>
Figura 4.47 - Ejemplo de patrón de la llamada a un procedimiento de CL
Este patrón se encarga que traducir las llamadas a procedimientos. Esta regla recibe el
nombre de procCall. procCall contiene una serie de parámetros que recibe como
información para instanciar el patrón.
Como se puede apreciar en el ejemplo, los StringTemplates permiten el uso de

iteradores y condicionales.
Veamos ahora como serían las llamadas a las reglas de la Figura 4.46 y Figura 4.47
desde el punto concreto del programa donde decidimos el patrón por el que se ha de
traducir:
| ^( WRITELN
STRING_CONST -> writelnString(string={$STRING_CONST.text})
Figura 4.48 - Llamada al patrón de la Figura 4.46 desde el código en CL
Aparece destacada la llamada al StringTemplate writelnString. El símbolo “->”

indica concretamente que se va a utilizar el patrón de traducción de nombre
writelnString y entre paréntesis se especifica el nombre de sus parámetros seguido
del valor que reciben en la llamada. El parámetro que se pasa (string), toma por valor
el texto del token STRING_CONST.
A continuación se muestra la llamada al StringTemplate procedure. Igual que en el

ejemplo anterior, aparece destacada la llamada al StringTemplate. La semántica es la
misma que para el anterior ejemplo, pero esta vez se puede observar la aplicación de
condicionales dentro de la llamada.

procedure
@init {
Integer temp;
}
: ^( PROCEDURE IDENT
{ symTab.pushScope($IDENT.text); }
proc_header
l_vars
l_blocks
{ temp = 0;
resetLabelCounters();
resetAuxSpace();
}
l_instrs[temp]
{ symTab.popScope(); }
)
-> procedure(id={symTab.getFullName($IDENT.text)},
params={$proc_header.st},
vars={$l_vars.st},
auxspace={auxspaceMaxim>0?auxspaceMaxim:null},
instrs={$l_instrs.st},
subrs={$l_blocks.st})
;
Figura 4.49 - Llamada al patrón de la Figura 4.47 desde el código en CL

Capítulo 5. Definición de los Lenguajes Aplicados
5. Definición de los Lenguajes Aplicados

Ahora que ya hemos comprendido en más detalle el funcionamiento de las
diferentes fases del compilador y de las herramientas usadas para desarrollar este
proyecto, es necesario conocer los lenguajes con los que se ha trabajado para cada una
de las partes elaboradas.
Durante la realización del proyecto se ha trabajado con tres lenguajes diferentes: el

lenguaje CL del código fuente, el lenguaje Z-Code para la representación intermedia y
el código ensamblador IA-32. Cada uno de ellos se ha trabajado en diferentes fases de
desarrollo del compilador.
CL es un lenguaje de propósito académico que se estudia en la asignatura de

Compiladores y es para él se realiza un compilador como parte de la práctica de la
asignatura. En este proyecto también usaremos CL como lenguaje de código fuente.
CL es un lenguaje imperativo, sencillo y limitado en cuanto a funcionalidades como

veremos más adelante. Su sintaxis es muy similar a la de Pascal.
Z-Code por su parte, es el nombre que recibe el código intermedio al que se va a

traducir el lenguaje CL. Se trata de un lenguaje de tres direcciones similar a pseudo-
código de bajo nivel.
Finalmente, IA-32 es el lenguaje ensamblador al que se va a traducir el lenguaje Z-

Code, aunque en este capítulo sólo se profundizará en los lenguajes CL y Z-Code,
postponiendo la explicación de IA-32 al capítulo 6.
A modo gráfico, veremos la compilación de un programa CL como la siguiente

secuencia de traducciones:
Figura 5.1 - Proceso de traducción del código fuente a código objeto

5.1. Lenguaje CL
5.1.1. Estructura
La estructura básica de un programa CL está comprendida entre las palabras
clave program y endprogram. Dentro del programa podremos declarar tipos y variables
globales, funciones y procedimientos, además de especificar las instrucciones.
Podríamos decir que se trata de un lenguaje pensado para realizar una programación
modular, en el que se pueden definir bloques de funcionalidad (funciones y
procedimientos) de forma anidada.
La estructura básica de un programa CL es la siguiente:
program
types
/*Declaración de tipos*/
endtypes
vars
/*Declaración de variables*/
Endvars
/*Procedimientos y Funciones*/
/*Instrucciones*/
endprogram
Figura 5.2 - Estructura de un programa en CL
A continuación se muestran dos ejemplos de programas CL, uno de ellos mucho más
sencillo que el otro.
El primer ejemplo muestra un programa que calcula el factorial de un número que lee
por pantalla. El segundo crea un árbol a partir de punteros a un tipo estructurado
definido por el usuario. Este tipo estructurado contiene la información habitual de los
árboles de programación.

program
vars
x int
i int
fact int
endvars
i := 1
read(x)
if x = 1 then
fact := 1;
else
fact := 1
while i <= x do
fact := fact * i;
i := i + 1;
endwhile
endif
writeln(fact);
endprogram
Figura 5.3 - Programa en CL: ejemplo sencillo
program
types
arbolnode struct
info int
firstchild pointer to arbolnode
nextsibbling pointer to arbolnode
endstruct
endtypes
vars
A pointer to arbolnode
aux2 pointer to arbolnode
endvars
function crearhoja(val info int) return pointer to arbolnode

vars
aux pointer to arbolnode
endvars
new(aux)
aux^.info := info
aux^.firstchild := null
aux^.nextsibbling := null
return aux
endfunction

function enraizarlistaarboles(val info int, ref A pointer to

arbolnode) return pointer to arbolnode
vars
aux pointer to arbolnode
endvars
new(aux)
aux^.info := info
aux^.firstchild := A
aux^.nextsibbling := null
return aux
endfunction
procedure anyadirhermanoizquierdo(ref A pointer to arbolnode, ref

L pointer to arbolnode)
A^.nextsibbling := L
endprocedure
procedure destruyearbol(ref A pointer to arbolnode)

if not (A = null) then
destruyelistaarboles(A^.firstchild)
free(A)
endif
endprocedure
procedure destruyelistaarboles(ref L pointer to arbolnode)

if not vacia(L) then
destruyelistaarboles(L^.nextsibbling)
destruyearbol(L)
endif
endprocedure
procedure escribirarbol(val n int, val A pointer to arbolnode)

vars
num int
endvars
procedure escribirlistaarboles(val L pointer to arbolnode)
if not vacia(L) then
escribirarbol(num, primero(L))
num := num + 1
escribirlistaarboles(resto(L))
endif
endprocedure
write(n)
write(" ")
writeln(raiz(A))
num := 1
escribirlistaarboles(hijos(A))
endprocedure

function raiz(ref A pointer to arbolnode) return int

return A^.info
endfunction
function hijos(ref A pointer to arbolnode) return pointer to

arbolnode
return A^.firstchild
endfunction
function primero(ref L pointer to arbolnode) return pointer to

arbolnode
return L
endfunction
function resto(ref L pointer to arbolnode) return pointer to

arbolnode
return L^.nextsibbling
endfunction
function vacia(ref L pointer to arbolnode) return bool

return L = null
endfunction
{
A := a
/ \
b c
/ \ / \
d e f g
la informacion de los nodos (a, b, ..., g)

se guarda como enteros (101, 102, ..., 107)
}
aux2 := crearhoja(104)
anyadirhermanoizquierdo(aux2, aux3)
aux3 := enraizarlistaarboles(102, aux2)
aux5 := enraizarlistaarboles(103, aux4)
A := enraizarlistaarboles(101, aux3)
escribirarbol(1, A)
destruyearbol(A)
endprogram
Figura 5.4 - Programa en CL: ejemplo complicado

5.1.2. Valores y Tipos

Los tipos con los que cuenta el lenguaje CL son:
 Tipos básicos: enteros y booleanos con su significado habitual.
 Tipos estructurados: arrays, structs y punteros, que se declararán usando la

sintaxis:
o ARRAY [tamaño] OF tipo
o STRUCT lista_de_campos ENDSTRUCT
o POINTER TO tipo
 Nombres de tipos definidos por el usuario a partir de otros tipos del lenguaje.
Se declaran entre los delimitadores TYPES y ENDTYPES al comienzo del programa
principal y sólo en él, tras la palabra clave PROGRAM.
El tipo string no existe como tal, es decir, no podemos declarar un identificador de

tipo string, pero podemos utilizar cadenas de caracteres (valores) para
entrada/salida.
5.1.3. Expresiones
Las expresiones con las que contamos en CL son las habituales en la mayoría de
los lenguajes de programación:
 Expresiones con operadores binarios y unarios:
o Expresiones aritméticas: +, - , * , / y el - unario.
o Expresiones de comparación: =, <, >.
o Expresiones lógicas: AND, OR y NOT.
 Expresiones con accesos a arrays, structs o con punteros:
o Acceso a un elemento de un array: expr1[expr2].
o Acceso a un campo de un struct: expr1.nombre.
o Acceso al objeto apuntado por un puntero: expr1^, o valor de la

dirección de una expresión: &expr1.

 Llamadas a funciones. El paso de parámetros a funciones se puede realizar por

valor o por referencia y éstas pueden devolver tanto valores de tipo básico como
tipo estructurado.
La prioridad que establecemos para los operadores de mayor a menor es:
 [], .,^
 NOT , - unario, @ (dirección)
 *,/
 +,-
 =,<,>
 AND , OR
Los operadores que se encuentran en un mismo nivel tienen la misma prioridad. En este
caso, cuando exista ambigüedad se asumirá asociatividad izquierda de todos los
operadores binarios. Como es habitual, si queremos utilizar otra prioridad o
asociatividad podemos usar los paréntesis.
5.1.4. Instrucciones
CL dispone de los siguientes tipos de instrucciones:
 Instrucciones de asignación. Que tienen la forma habitual:
o expr1: = expr2
 Sentencias alternativas:
o Cuenta con las estructuras if/then e ifthen//else, que son de la forma:
- IF expr THEN l_instrs ENDIF
- IF expr THEN l_instrs1 ELSE l_instrs2 ENDIF
 Sentencias iterativas:
o La única sentencia de bucle es while, y tiene la siguiente estructura:
- WHILE expr DO l_instrs ENDWHILE
 Llamadas a procedimientos. Son del tipo:

o P(param1,..., paramn). El paso de parámetros a procedimientos se puede

realizar por valor o por referencia.
 Llamadas a operaciones de entrada/salida: write, writeln y read.
 Llamadas a operaciones de gestión de memoria dinámica: new y free.
5.1.5. Aspectos Semánticos del Lenguaje

En este apartado se tratarán algunos de los aspectos semánticos de CL. Es
necesario conocerlos para poder determinar la corrección de un determinado programa
fuente escrito en CL.
Algunos de estos aspectos a tener en cuenta son:
 Equivalencia de tipos. La definición de la noción de equivalencia de tipos ya

se trató en el capítulo 2, simplemente destacar el hecho que CL trabaja con la
noción de equivalencia de tipos estructural, ya que es menos restrictiva.
 Coerción de tipos. La coerción de tipos consiste en la conversión implícita de
un tipo a otro. CL no permite la coerción de tipos, en este caso de booleanos a
enteros.
 Paso de parámetros. El paso de parámetros puede ser por valor o por
referencia con la semántica habitual. Cuando se pasa un parámetro por valor, se
pasa el valor de la expresión original, mientras que cuando es por referencia, se
pasa la dirección de la expresión original. Por tanto, cuando se pasa un
parámetro por referencia, cualquier modificación que tenga lugar dentro del
procedimiento o función afectará directamente al valor del parámetro actual
 Reglas de visibilidad. Las reglas de visibilidad de un lenguaje permiten saber
dónde se puede usar un determinado identificador. Un identificador debe ser
visible en el lugar del código donde se desea hacer uso de él.
CL permite declarar procedimientos y funciones y también, la declaración de

nuevos procedimientos y funciones de forma anidada. Cada función o
procedimiento determina un ámbito.
Veamos un ejemplo que nos permita observar con más detalle estos conceptos:

program
vars
a array[10] of int
b int
endvars
procedure P(val A array[10] of int, ref B array[10] of int)
b := 0
while b <10 do
writeln(A[b])
writeln(B[b])
b := b + 1
endwhile
endprocedure
function F(val c int, ref d int)return int
vars
a int
endvars
a:= c + d
return a
endfunction
b := 0
while b <10 do
a[b] := b
b := b+1
endwhile
P(a, a)
b := F(b+1, b)
b := F(b, b)
endprogram
Figura 5.5 - Programa en CL: Ejemplo de reglas de visibilidad
En el ejemplo anterior podemos observar que existen tres ámbitos diferentes:
- Ámbito del programa principal que declara los símbolos: a, b, P y F.
- Ámbito del procedimiento P que declara los símbolos A y B.
- Ámbito de la función F que declara los símbolos c, d y a.
Los símbolos declarados en el ámbito del programa principal tienen un alcance

global. Los ámbitos del procedimiento P y la función F definen símbolos
locales. Los parámetros formales y las variables declaradas dentro de estos
ámbitos sólo son visibles localmente.
En la función F, son visibles y por tanto se pueden usar los siguientes símbolos:
c, d y a declarados localmente, y los símbolos b, P y F declarados en el
programa principal. La declaración de la variable a (array) del programa
principal no es visible puesto que ha sido ocultada por la definición de la

variable local a (entero) de F. Nótese que desde F es posible realizar tanto una
llamada recursiva a F como una llamada al procedimiento P, y lo mismo ocurre
para P, podemos llamar a F aunque ésta haya sido declarada como un hermano
posterior.
Consideremos ahora un ejemplo de código con funciones y procedimientos

anidados:
program
vars
X int
Y int
endvars
function F1(val X int, ref Y int)return int
function F11(val X int, ref Y int)
write(111)
endfunction
write(112)
endfunction
write(11)
endfunction
F11(X, Y)
endfunction
procedure P2(val X int, ref Y int)
writeln(Y)
endprocedure
writeln(Y)
endprocedure
Y := Y-1
if 0 < Y then
P221(X,Y)
else
X := 1
endif
endprocedure
endprocedure
endprocedure
X := 1
Y := 2
P2(X,Y)
writeln(Y)
endprogram
Figura 5.6 - Ejemplo de programa CL con procedimientos y funciones anidados

A continuación se muestra la estructura de bloques del ejemplo anterior, donde

por un bloque entendemos un procedimiento o una función.
Figura 5.7 - Estructura de bloques del programa de la Figura 5.6
El lenguaje CL define unas reglas de visibilidad que permiten establecer qué

símbolos son visibles en cada punto del programa. Estas reglas determinan que
en un ámbito concreto, en primer lugar son visibles los símbolos declarados
localmente y, además, son visibles los símbolos declarados en ámbitos que son
ancestros del ámbito donde nos encontramos. Además, se establece que una
declaración en un ámbito más próximo anula u oculta una declaración hecha en
un ancestro más lejano.
Aplicando estas reglas, en el ámbito de P221 son visibles los símbolos locales
X e Y, el propio procedimiento P221 declarado en P22, los símbolos P21 y P22
declarados en P2 y finalmente, los símbolos F1 y P2 declarados en el ámbito
del programa principal.
5.2. Z-Code
A continuación definiremos cómo es el código intermedio al que vamos traducir
el lenguaje CL. En la práctica de la asignatura Compiladores ya se generaba código
intermedio (T-Code), pero éste era diferente al generado ahora.

T-Code era un código mucho más cercano al lenguaje ensamblador mientras que el
nuevo código intermedio Z-Code intenta ser más próximo a un lenguaje de alto nivel.
En este proyecto se ha planteado la generación de un código intermedio que facilitara la

lectura y el entendimiento, pero sobre todo pensando en que en el futuro sea más
sencillo realizar la optimización del código intermedio.
El código intermedio generado es un código de tres direcciones, es decir, la mayoría de

las instrucciones especifican dos direcciones para los posibles operandos, el operador a
aplicar y una dirección donde se guardará el resultado. A partir de ahora nos referiremos
siempre a este código como Z-Code.
5.2.1. Estructura
La estructura básica de un programa Z-Code será siempre:
program:
; parameters
; static_link
; endparameters
;
; variables
; /* declaración de variables*/
; endvariables
/*instrucciones programa principal*/
stop
/*CÓDIGO DIFERENTES BLOQUES: procedimientos y funciones, como por

ejemplo:*/
program_P:
; parameters
; returnvalue //caso de funciones
; /* parámetros del procedimiento o función*/
; static_link
; endparameters
;
; variables
; /* declaración de variables*/
; endvariables
/*instrucciones*/
retu
Figura 5.8 - Estructura de un programa en Z-Code

Como podemos observar, todo programa Z-Code está formado por una secuencia de
bloques de código. El primer bloque es siempre el programa principal, con su respectiva
declaración de parámetros (en este caso sólo static_link) y variables locales, y el código
correspondiente a sus instrucciones. Este bloque acaba siempre con la instrucción stop.
A continuación vendrían los siguientes bloques. Cada función o procedimiento genera

un bloque dentro del código, precedido por su etiqueta con el nombre completo del
procedimiento o función. Por ejemplo, program_P:. Este nombre nos indica que P es
un procedimiento declarado dentro del ámbito del programa principal. La ruta completa
la podemos ver como el recorrido que hay hasta llegar al nodo de aquél procedimiento o
función dentro del árbol de la estructura de bloques. Estos bloques siempre acaban con
la instrucción retu.
5.2.2. Operandos
Z-Code cuenta con dos clases de operandos, nucleares y no nucleares. Los
operandos nucleares son:
 Registros temporales. El lenguaje Z-Code permite utilizar temporales para

realizar cálculos intermedios. Los temporales tienen un identificador de la
forma: tN , donde N es cualquier número entero mayor o igual a 0).
Durante la generación de Z-Code, se ha supuesto que se dispone de un número

ilimitado de temporales. Si bien se ha intentado minimizar el número de los
temporales usados, en la mayoría de casos, existen otros en el que el uso que se
ha hecho no es el más óptimo posible puesto que no ha sido objeto de estudio en
este trabajo la optimización de estos recursos.
 Constantes. Dado que CL sólo trabaja con números enteros, las constantes serán
números enteros. Los valores booleano true y false se corresponden con los
enteros 1 y 0.
 Identificadores. Cualquier nombre de una variable o parámetro es un posible

operando de las instrucciones de CL.
 Tres operandos especiales con los que contaremos serán static_link, aux_space
y returnvalue, que representan direcciones simbólicas para acceder a algunas
posiciones del bloque de activación en curso.
Los operandos no nucleares son:
 ident[X], que denota el acceso a la posición de memoria X número de bytes más

allá de la dirección asociada a ident. X puede ser cualquier operando nuclear.

 ti [X] , que denota el acceso a la posición de memoria X número de bytes más

allá de la dirección contenido en el temporal ti. X puede ser cualquier operando
nuclear.
 *ident, que denota el acceso a la dirección de memoria a la que ident apunta.
 *ti, que denota el acceso a la dirección de memoria a la que ti apunta.
Una cadena de caracteres de la forma “........”, también representa un operando para

algunas instrucciones como las de escritura.
5.2.3. Instrucciones
Los tipos de instrucciones que generaremos son:
 Instrucciones de asignación, que pueden ser las siguientes, donde se

sobreentiende que a la izquierda de la asignación sólo puede haber un operando
referenciable:
o op1 = op2 op op3, donde op1, op2 y op3 son operandos nucleares y; op
es un operador binario aritmético, de comparación o lógico.
o op1 = op op2, donde op1 y op2 son operandos nucleares y op es una

operador unario, que en nuestro caso sólo puede ser el operador lógico
NOT o bien el operador aritmético – unario.
o op1 = op2, donde op1 y op2 son operandos nucleares. Estas son
instrucciones de copia donde el valor del op2 se asigna a op1.
o op1[op2] = op3, donde op1, op2 y op3 son operandos nucleares. Se

asigna a la posición op2 de memoria a partir de op1, el valor de op3.
o op1 = op2[op3], donde op1, op2 y op3 son operandos nucleares. Se

asigna a op1 el valor de la posición op3 de memoria a partir de op2.
o op1 = *op2, donde op1 y op2 son operandos nucleares. Se asigna a op1,
el contenido de a lo que apunta el puntero op2.
o *op1 = op2, donde op1 y op2 son operandos nucleares. Se asigna el

valor de op2 a lo que apunta el puntero op1.
o op1 = &op2, donde op1 y op2 son operandos nucleares. Se asigna la

dirección de memoria del identificador op2 a op1.

 Instrucciones de llamada y retorno a bloques:
o call name, donde name es el nombre completo del procedimiento o de

la función.
o retu, para el retorno de un procedimiento o función.
o stop, para finalizar el programa principal.
 Instrucciones de entrada/salida:
o wrii op1, donde op1 es un operando nuclear.
o wris op1, donde op1 es un string.
o wrln.
o reai op1, donde op1 es un operando nuclear.
 Instrucciones de manejo de la pila:

o push op1, donde op1 es un operando nuclear.
o pop, que no requiere ningún operando.
 Instrucciones de control de flujo:
o goto name, donde name es el nombre de la etiqueta objeto de un salto

incondicional.
o Sentencias de salto condicional con la siguiente estructura.
- if !op1 goto name, donde op1 es una expresión nuclear y name es

el nombre de la etiqueta que representa la dirección donde se realiza
el salto si op1 es falso (contiene el valor 0).
 Otras instrucciones:
o copy op1 op2 size, donde op1 y op2 son operandos nucleares y size
indica el número total de bytes que se van a copiar.
 Nombres de etiquetas. Dentro del código se pueden especificar etiquetas que

representan direcciones simbólicas a las que se puede saltar desde otros puntos
del programa y que tienen la sintaxis:
o name :

A continuación se muestra un ejemplo sencillo de programa escrito en CL, con su

correspondiente traducción a Z-Code.
program
vars
x int
s struct
z1 int
z2 int
endstruct
a array[5] of int
endvars
x:=3
s.z1 := 4
a[x] := s.z1
endprogram
Figura 5.9 - Ejemplo de programa CL
program:
; parameters
; static_link
; endparameters
;
; variables
; x 4
; s 8
; a 20
; endvariables
x := 3
s[0] := 4
t1 := x * 4
t2 := s[0]
a[t1] := t2
stop
Figura 5.10 - Traducción en Z-Code del programa de la Figura 5.9

Capítulo 6. Trabajo Realizado
6. Trabajo Realizado
Hasta el momento hemos tratado los diversos aspectos teóricos relacionados con
la construcción de compiladores y la herramienta usada para la realización de este
proyecto.
El objetivo final es implementar un compilador para el lenguaje CL. Como ya bien se

ha comentado, este lenguaje es el usado en la asignatura de Compiladores.
En esa misma asignatura ya se implementan diferentes partes de ese compilador, pero el

trabajo de este proyecto consiste en realizarlo haciendo uso de las nuevas posibilidades
que proporciona ANTLR v3, además de introducir ampliaciones del lenguaje CL y una
nueva codificación de código intermedio.
En los siguientes apartados detallaremos cuál ha sido el trabajo realizado en este

proyecto. Principalmente agruparemos las tareas realizadas en tres partes:
 Ampliación léxica, sintáctica y semántica del lenguaje CL.
 Generación del nuevo código intermedio Z-Code.
 Generación del código ensamblador IA-32.
El trabajo ha consistido en construir un compilador que, dado un programa en lenguaje

CL, obtenga como salida un código equivalente en lenguaje ensamblador IA-32.
Además, este compilador es capaz de detectar errores léxicos, sintácticos y semánticos
en el programa fuente.
El Anexo Ejemplo del Proceso de Compilación Completo muestra un ejemplo completo

de todo el proceso de compilación para un determinado programa fuente. En él se puede
observar el resultado obtenido de las diferentes fases de compilación.
6.1. Trabajo Previo

Hay que destacar que este proyecto no es un trabajo que parte de cero, sino que
ya existían partes implementadas. En estas partes ya implementadas se han realizado
ampliaciones y modificaciones.
Las partes ya implementadas de las que se ha partido para este proyecto eran las de la
etapa de análisis o Front-end del compilador.
El proyecto ya contaba con una estructura de ficheros que facilitan el desarrollo y testeo
del compilador. Esa estructura es la siguiente:

Figura 6.1 - Estructura de ficheros del compilador
 En el directorio complete podemos encontrar todas las clases que implementan

las diferentes etapas del compilador.
 En el directorio jps se encuentran todos los juegos de pruebas implementados

para testear todas las diferentes partes del compilador.
 Y, finalmente, tenemos un directorio donde encontramos los diferentes

shellscripts que testean el compilador con los juegos de pruebas del directorio
jps. Existe un test diferente para cada juego de prueba y fase del compilador.
Toda nueva clase, shellscript o juego de pruebas ha sido creado respetando la estructura
de ficheros existente.
6.2. Archivos que intervienen en las diferentes fases

En cada una de las etapas del compilador se ha desarrollado en unos
determinados ficheros.
 El Lexer y el Parser de CL, es decir, la lista de tokens y la gramática, se definen

en el fichero CL.g.
 La fase de Análisis Semántico está implementada en el fichero TypeCheck.g.
 Los ficheros que implementan la generación de código intermedio son:
o CodeGen.g: implementa la generación del Z-Code con las respectivas

llamadas a los templates del fichero CodeGen.stg.
o CodeGen.stg: contiene la librería de StringTemplates que generan el Z-

Code.
 La generación de código ensamblador se implementa mediante tres ficheros

diferentes:

o ZCode.g: es la gramática que define el lenguaje Z-Code. En ella se

introducen acciones que permiten ir almacenando la información
relevante para la etapa de traducción a IA32.
o ZCode.java: contiene la implementación de la clase Z-Code, que permite

representar internamente el código Z-Code. También hay implementadas
otras clases auxiliares.
o ZCodeTOIA32.java: es la clase que implementa puramente el traductor a

IA32 a partir de la estructura interna que recibe, y que ha sido generada
en el fichero.
6.3. Trabajo Realizado

La forma más clara de describir el trabajo realizado durante el proyecto es, como
en otras ocasiones, siguiendo el orden de las etapas del compilador.
Además, el trabajo realizado será explicado en orden de implementación. Por lo tanto,

se seguirá el siguiente orden:
 Etapa de Análisis o Front-end. Se explicarán las ampliaciones y modificaciones

realizadas en las fases de Análisis Léxico, Sintáctico y Semántico.
 Generación de Código Intermedio o Middle-end. Se podrá ver cómo se ha
realizado la traducción del lenguaje CL al lenguaje Z-Code.
 Generación del Código Ensamblador o Back-end. En este caso veremos cómo
se ha realizado la traducción del lenguaje Z-Code al lenguaje ensamblador IA-
32.
6.3.1. Etapa Análisis o Front-end

Como ya hemos visto a lo largo de este documento, la etapa de Análisis está
formada por las fases de Análisis Léxico, Sintáctico y Semántico.
En esta etapa el trabajo realizado ha consistido en ampliar el lenguaje CL de manera que

permita:
 Definición y uso de tipos determinados por el usuario en un apartado previo a la

declaración de variables.
 Uso de punteros y gestión de memoria dinámica con las correspondientes

operaciones: new y free.

La introducción de estas novedades en el lenguaje CL afecta a todas las fases de la etapa

de Análisis o Front-end.
Veamos algunos pequeños ejemplos de aplicación estas novedades hasta el momento no

incluidas en CL.
6.3.1.1. Types
La definición de tipos se engloba dentro de las palabras clave types y endtypes

justo después de la palabra clave program. Estos tipos sólo se pueden definir en el
ámbito del programa principal, y se pueden definir usando cualquier otro tipo.
Al permitir que el usuario pueda definir nuevos tipos, se ha tenido que definir una
noción de equivalencia de tipos. Entre la noción de equivalencia estructural y la de
equivalencia por nombre, se ha optado por la primera como ya se ha explicado en el
capítulo 2.
A continuación se muestra un ejemplo de uso de tipos definidos por el usuario:

program
types
t struct
b int
c int
endstruct
A array [1000] of int
endtypes
vars
v A
w A
a t
d int
endvars
procedure P(ref x t, ref y int, ref z A, val t A)
x.c := y
y := y + x.b * x.c
z[0] := y - 1
z[999] := y - 1
t[0] := y + 1
t[999] := y + 1
endprocedure
a.b := 2
a.c := 3
d := 10
w[0] := 333
w[999] := 333
P(a, d, v, w)
endprogram
Figura 6.2 - Programa en CL con definición de tipo estructurado
program
types
tA array[3] of int
tB array[3] of int
endtypes
vars
a array[10] of tA
b array[20] of tB
endvars
a[2] := b[5]
endprogram
Figura 6.3 - Programa en CL con definición de tipos

Como se puede ver en el ejemplo de la figura anterior, la instrucción a[2] := b[5] es

posible debido a la noción de equivalencia estructural de tipos previamente comentada.
Asimismo, en la declaración de tipos definidos por el usuario es necesario controlar la

existencia de posibles circularidades en su definición. A continuación se muestra un
ejemplo de circularidad.
program
types
tA struct
next pointer to tA
info int
endstruct
endtypes
endprogram
Figura 6.4 - Ejemplo de definición circular de tipos
Como se puede observar en el ejemplo anterior. El tipo de uno de los campos del struct,
es del tipo definido por el usuario, dando lugar a una circularidad.
6.3.1.2. Punteros y memoria dinámica
La figura inferior muestra un primer ejemplo de un programa sin errores

sintácticos ni semánticos, aunque se producirán errores en su ejecución.
program
vars
ppi pointer to pointer to array[10] of int
A array[10] of int
endvars
ppi := null
ppi^ := null
ppi^^ := A
ppi^^[3] := 23
endprogram
Figura 6.5 - Programa en CL con punteros
La ejecución del siguiente programa muestra por pantalla los números 3 y 5.

program
vars
p pointer to int
i int
endvars
new(p)
i := 3
p := @i
writeln(p^)
p^ := 5
writeln(i)
free(p)
endprogram
Figura 6.6 - Programa en CL con punteros
Los punteros de CL pueden apuntar a cualquier tipo definido en el lenguaje o bien, a

tipos definidos por el usuario.
Dada una expresión expr de tipo pointer(T) para algún tipo T, el significado de las
instrucciones y los operadores con punteros es la siguiente:
 expr^, accede al objeto apuntado por la expresión expr.
 @expr1, dada la expresión expr1 de cualquier tipo T, devuelve la dirección

donde se encuentra expr1. Esta expresión tiene que ser referenciable.
 new(expr), esta instrucción pide al gestor de memoria dinámica size(T) bytes y

asigna a expr la dirección de memoria donde empieza el espacio reservado.
 free(expr), libera el espacio de memoria apuntado por la expresión expr.
Como bien se ha comentado, estas dos incorporaciones han introducido modificaciones

en dos archivos diferentes:
 CL.g: la gramática de CL ahora debe permitir la declaración y uso de punteros y

la declaración de nuevos tipos, creando los subárboles AST correspondientes.
También ha sido necesario la definición de nuevos tokens.
 TypeCheck.g: se han incorporado todas las comprobaciones semánticas

necesarias para el uso correcto de punteros y de las instrucciones new y free.
También es necesario comprobar que las declaraciones de nuevos tipos no
contienen ciclos.
Con esto concluye la primera y más breve etapa del proyecto.

6.3.2. Generación de Código Intermedio o Middle-end

Esta es la parte principal del proyecto y por tanto, a la que se le ha dedicado la
mayor parte de tiempo.
Ya hemos explicado en el capítulo 3 de este documento cuál era el objetivo principal de

la generación de código intermedio y en especial, el de nuestro lenguaje intermedio, Z-
Code en el capítulo 5. Pero es interesante hacer énfasis en que el trabajo desarrollado en
esta etapa pretende ser los cimientos para permitir una futura optimización de forma
más sencilla que antes.
También hemos definido en el capítulo 5 cómo es la sintaxis de Z-Code. Por lo tanto,

ahora nos centraremos en especificar cuáles han sido los patrones de traducción
utilizados.
Para expresar la traducción de CL a Z-Code usada, definiremos en primer lugar una

notación que nos permitirá entender con mayor facilidad este proceso.
Consideraremos que existen tres funciones como las siguientes:
 GenZ-CodeInstruction (instr)  [Z-CodeList]. Dada una instrucción instr en

lenguaje CL, genera un conjunto de instrucciones Z-CodeList equivalente. Estas
instrucciones pueden utilizar cualquiera de los registros temporales ti.
 GenExprAddress (expr, temp)  [exprText, isExprNuclear, Z-CodeList].

Dada una expresión expr y un número de temporal temp, GenExprAddress
genera unas instrucciones Z-CodeList que al ser ejecutadas, calculan la
dirección de expr. El parámetro temp indica cuál es el primer temporal libre
para usar.
o exprText: es la Z-expresión que guarda la dirección de expr.
o isExprNuclear: es un booleano que nos indica si exprText es nuclear. La

definición de expresión nuclear ya ha sido comentada en el capítulo 5.
o Z-CodeList: al igual que para el caso de GenZ-CodeInstruction, se trata

del conjunto de instrucciones Z-Code que calculan la dirección y la
guardan en exprText.
 GenExprValue (expr, temp)  [exprText, isExprNuclear, Z-CodeList].

Este caso es similar a GenExprAddress. La diferencia radica en el hecho que
ahora, al ejecutarse la traducción, calculará el valor de la expresión en lugar de
la dirección. Los parámetros de entrada y los resultados también tienen el
mismo significado que para el caso anterior.
Antes de continuar veremos dos ejemplos de patrones sencillos para poder comprender
con mayor facilidad los que se presentarán en los siguientes apartados.

...
s struct
a int
b int
c int
endstruct
...
s.b := 4
...
Figura 6.7 - Ejemplo I de programa CL para la generación de Z-Code
Supongamos el ejemplo de la figura anterior. Si en un punto de un programa nos

encontramos con la instrucción s.b := 4, el correspondiente patrón de traducción para
el cálculo de la dirección de s.b nos retornará la tupla <”a[4]”, false, vacio>
correspondiente a la tupla que devuelve la función GenExprAddress (expr, temp). En
este caso, la Z-CodeList es vacía puesto que su traducción se devuelve directamente
como primer elemento de la tupla (a[4]). Además, como se puede observar, se retorna
un false que indica que el primer elemento de la tupla no es nuclear.
Veamos un nuevo ejemplo de traducción:
program
vars
i int
a int
endvars
...
i := 5
a := 3 + 2 * i
...
endprogram
Figura 6.8 - Ejemplo II de programa en CL para la generación de Z-Code
En este caso, la traducción de la expresión 3 + 2 * i, generada mediante la función

GenExprValue (expr, temp) devolvería como resultado la tupla <”temp”, true, Z-
CodeList>. A diferencia del ejemplo de la Figura 6.7, ahora se devuelve una lista de
instrucciones Z-CodeList, el motivo de esto es que como ahora, para poder generar la
traducción, es necesario realizar más de una llamada a las funciones previamente
presentadas. Es decir, se realizará una primera llamada a la función GenExprValue (3
+2 * i, temp), esta llamada además, realizará nuevas llamadas a GenExprValue para el
cálculo de la multiplicación y de la suma. Por lo tanto, al final de todo tendremos la
concatenación de los resultados de todas esas llamadas, retornada como una Z-CodeList.

Por ello mismo, el valor estará almacenado en un registro temporal temp y se trata de un
nuclear.
Además de estas tres funciones principales, definiremos otras funciones auxiliares, que
veremos al final del apartado para facilitar la comprensión, y la notación usada para la
descripción de los templates o patrones de traducción.
Dispondremos de las siguientes funciones auxiliares:
 isVarLocal(expr). Se trata de una función que evalúa si la expresión pasada

como parámetro es una variable local.
 isParamVal(expr). Igual que el caso anterior, pero en este caso comprueba si

es un parámetro por pasado por valor.
 isParamRef(expr). La misma semántica que en los casos anteriores, pero

comprobando si es un parámetro pasado por referencia.
 isTypeBasic(expr). Comprueba si expr es una expresión de tipo entero o

booleano.
 isTypeBasicOrPointer(expr). Esta función devuelve cierto si expr es de tipo

entero, booleano o puntero a cualquier tipo.
 isTypePointer(expr). Comprueba si expr es una expresión de tipo puntero.
 isString(expr). Comprueba si expr es un string.
 isRef(expr). Esta función retorna cierto cuando expr es una expresión

referenciable, es decir, de la cual se puede calcular su dirección de memoria.
 offsetField(expr, ident). Dada una expresión expr de tipo struct y un campo

ident, devuelve el offset (número de bytes desde el principio del struct) de dicho
campo.
 sizeOf(expr). Devuelve el tamaño del tipo de la expresión expr.
 sizeOfArrayElem(expr). Esta función devuelve el tamaño de los elementos del

array expr.
 returnType(ident). Devuelve como resultado el tipo que retorna la función

ident.
A partir de ahora hablaremos de tipos escalares, generalmente, para referirnos a los

tipos entero, booleano y puntero; mientras que los no escalares serán arrays y structs.
Es también necesario definir el concepto de clase de un identificador. Si un identificador

ident denota un objeto referenciable, su clase puede ser variable local, parámetro por

referencia o parámetro por valor. Otras clases de identificadores son los nombres de
tipos, los procedimientos y las funciones.
Como ya hemos comentado se especificarán los patrones de traducción en un pseudo-

código que utiliza la siguiente notación:
 “||” para indicar la concatenación de Z-Code. Cabe destacar el hecho cuando

se use la siguiente notación:
GenExprValue( expr1, temp) ||

GenExprValue( expr2, temp+1)
 [“exp1.exprText+exp2.exprText ”, false, Z-CodeList]
Figura 6.9 - Ejemplo I de concatenación en la generación de Z-Code
Realmente nos estaremos refiriendo a que se están concatenando las Z-

CodeLists resultantes de las traducciones GenExprValue( expr1, temp) y
GenExprValue( expr2, temp+1), dando como resultado una nueva Z-
CodeList formada por la concatenación de dos Z-CodeLists.
Cuando nos encontremos con notaciones del tipo:
GenExprValue(expr, temp) ||
temp := temp + offsetField(expr, IDENT)
[“expr.exprText[temp]”, false, Z-CodeList]
Figura 6.10 - Ejemplo II de concatenación en la generación de Z-Code
Nos estaremos refiriendo a que se concatena la Z-CodeList resultante del

patrón GenExprValue( expr, temp) con la instrucción inmediatamente
posterior al símbolo “||”, dando como resultado una nueva Z-CodeList
formada por la concatenación comentada.
 expr.exprText para referirnos al valor de exprText de la expresión expr.

exprText es un valor generado por la llamada a GenExprAddress(expr) o
GenExprValue(expr).
 expr.exprNuclear para referirnos a si expr es una expresión nuclear.

exprNuclear es un valor generado por la llamada a GenExprAddress(expr) o
GenExprValue(expr).
 offsetAux_space se refiere al espacio ya ocupado en aux_space.

 levelsDiff(ident) indica si ident ha sido definido en nuestro scope. Si levelsDiff

es igual a cero indica que está declarado en el ámbito actual. Si levelsDiff es
uno, indica que la variable o parámetro está declarado en el ámbito del padre
del ámbito actual y así sucesivamente.
 expr.text para indicar que nos referimos concretamente al texto de esa

expresión como un string
Se pueden utilizar parámetros en la definición de los patrones y éstos pueden contener

sentencias alternativas, iterativas,...de forma que pueden generar diferentes traducciones
en función de la información de entrada.
Para facilitar el entendimiento empezaremos con las traducciones más sencillas, para así
poder ir elevando el nivel de abstracción a medida que nos encontremos con cuestiones
más complicadas. También, agruparemos las traducciones por tipo de función con la
que se generarán.
Así pues, presentaremos los patrones de traducción siguiendo este orden:
 Generación del valor de expresiones. Se definirán los patrones sobre cómo se

genera el valor de los valores constantes, de las operaciones unarias y binarias,
de un identificador, del acceso al campo de un struct, del acceso al campo de un
array, el valor de la llamada a una función y el del uso de punteros.
 Generación de la dirección de expresiones. Se detallarán los patrones que
definen la traducción para conseguir la dirección de identificadores, el campo
de un struct, el elemento de un array o puntero.
 Generación de instrucciones. Se especifican los patrones para la generación del
código de las instrucciones de CL: sentencias condicionales e iterativas,
instrucciones de entrada/salida, llamadas a procedimientos, instrucciones de
asignación y finalmente, las instrucciones de gestión de memoria dinámica (new
y free).
6.3.2.1. Generación del Valor de Expresiones
En este apartado describiremos cómo conseguir instrucciones en Z-Code que al

ser ejecutadas calculen el valor de una expresión.
6.3.2.1.1. Valores constantes
Empezaremos definiendo el valor del conjunto de constantes con el que contamos.

 GenExprValue (INT_CONST, temp)  [“INT_CONST.text”, true, ]

 GenExprValue (TRUE, temp)  [“1”, true, ]
 GenExprValue (FALSE, temp)  [“0”, true, ]
 GenExprValue (NULL, temp)  [“0”, true, ]
Figura 6.11 - Generación del Z-Code para constantes
Como podemos ver, calcular el valor de constantes es muy sencillo puesto que no
necesita de generación de Z-Code. Simplemente se debe indicar cuál es el string con el
valor de la constante y devolver la información de si ese string es expresión nuclear.
6.3.2.1.2. Expresiones con Operadores Unarios
 GenExprValue (NOT expr, temp) :

GenExprValue( expr, temp)
 [“NOT exp.exprText”, false, Z-CodeList]
 GenExprValue (- expr, temp) :

GenExprValue( expr, temp)
 [“- exp.exprText”, false, Z-CodeList]
Figura 6.12 - Generación del Z-Code para operadores unarios
El cálculo del valor de expresiones con operadores unarios consiste en generar el valor
de la expresión en cuestión y, a continuación, añadirle el operador al string resultante.

6.3.2.1.3. Expresiones con Operadores Binarios:
 GenExprValue (expr1 AND expr2, temp) :

GenExprValue(expr1, temp) ||
GenExprValue(expr2, temp+1)
 [“exp1.exprText AND exp2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 OR expr2, temp) :

 [“expr1.exprText OR expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 +expr2, temp) :

 [“expr1.exprText + expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 - expr2, temp) :

 [“expr1.exprText - expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 * expr2, temp) :

 [“expr1.exprText * expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 / expr2, temp) :

 [“expr1.exprText / expr2.exprText ”, false, Z-CodeList]
Figura 6.13 - Generación del Z-Code para expresiones binarias

 GenExprValue (expr1 > expr2, temp) :

 [“expr1.exprText > expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1 = expr2, temp) :

 [“expr1.exprText = expr2.exprText ”, false, Z-CodeList]
 GenExprValue (expr1< expr2, temp) :

GenExprValue(expr2, temp)
 [“expr1.exprText < exp2.exprText ”, false, Z-CodeList]
Figura 6.14 - Generación Z-Code para expresiones binarias (II)
Para todas expresiones con un operador binario el tratamiento es el mismo. Se trata

siempre de generar el valor de las expresiones a cada lado del operador. El string
resultante está formado por los strings de cada expresión con el operador intercalado
entre ellos.
6.3.2.1.4. Identificador
Ahora que ya hemos visto algunos de los patrones de traducción más sencillos,
veamos el patrón que define la generación de código de los identificadores.
El patrón de generación del valor de un identificador es uno de los que más casuística
contempla, siendo por tanto, uno de los más complicados de implementar. Es por ello
que se ha pospuesto su presentación para este punto.

GenExprValue (IDENT, temp) :

si isTypeBasic(IDENT) && !isTypePointer(IDENT) entonces
si levelsDiff(IDENT) = 0 entonces
si isVarLocal(IDENT) entonces  [“IDENT.text”, true, ]
si isParamRef(IDENT) entonces  [“*IDENT.text”, false, ]
si isParamVal(IDENT) entonces  [“IDENT.text”, true, ]
sino
GenStaticLink(IDENT, temp)
[“*temp”, false, Z-CodeList]
si isTypePointer(IDENT) entonces
si isVarLocal(IDENT) entonces [“IDENT.text”, true, ]
si isParamRef(IDENT) entonces [“*IDENT.text”,false, ]
si isParamVal(IDENT) entonces [“IDENT.text”, false, ]
sino
GenStaticLink(IDENT, temp)
sino
GenExprAddress(IDENT, temp+1) ||
temp := &aux_space ||
temp := temp + offsetAux_space ||
copy temp+1 temp sizeOf(IDENT)
[“temp”, true, Z-CodeList]
Figura 6.15 - Generación del Z-Code para un identificador
A la hora de calcular el valor de un identificador hemos de tener en cuenta

principalmente tres cuestiones:
 Tipo del identificador. En función de si el identificador es de un tipo básico o

no deberemos de actuar de una u otra forma. Para el caso de tipos no básicos
siempre deberemos realizar una copia del valor.
 Ámbito en el que está declarado. Dependiendo de dónde esté declarado el

identificador, necesitaremos hacer un número de indirecciones determinado.

Este número viene determinado por el número de saltos de nivel que debemos
realizar para llegar a la definición del identificador.
 Clase de identificador. Según sea de una clase u otra, deberemos de actuar de

cierta manera.
6.3.2.1.5. Acceso al campo de un Struct
GenExprValue (expr.IDENT, temp) :

si isRef(expr.IDENT) && isTypeBasicOrPointer(IDENT) entonces
GenExprAddress(expr, temp)
[“expr.exprText[offsetField(expr,IDENT)]”, false, Z-CodeList]
sino si isRef(expr.IDENT) && !isTypeBasicOrPointer(IDENT) entonces

GenExprAddress(expr, temp) ||
temp+1 := temp + offsetField(expr, IDENT) ||
temp := temp + offsetAux_space ||
copy temp+1 temp sizeOf(expr.IDENT)
si expr.isExprNuclear
sino
sino
GenExprValue( expr, temp) ||
temp := temp + offsetField(expr, IDENT)
Figura 6.16 - Generación del Z-Code para el acceso a un campo de un struct
Calcular el valor del acceso al campo de un struct, básicamente consiste en generar la

dirección del struct y a continuación, sumarle el desplazamiento hasta llegar al campo
deseado. Finalmente, para sólo quedará cargar el valor.
Todo este cálculo se realiza de una manera determinada dependiendo del tipo del campo
del struct y de si es un struct referenciable.
El string resultante siempre será de la forma expr1[expr2], ya que entendemos expr1

como la dirección del struct y expr2 como el desplazamientro hasta el campo del struct.
6.3.2.1.6. Acceso Elemento de una Array:
GenExprValue (expr1[expr2], temp) :

si isRef(expr1 [expr2]) && isTypeBasicOrPointer(expr1 [expr2]) entonces
GenExprAddress(expr1, temp) ||
GenExprValue(expr2, temp+1) ||
temp+1 := temp+1 * sizeOfArrayElem(expr1)
[“ expr1.exprText[temp+1]”, false, Z-CodeList]
sino si isRef(expr1 [expr2]) && !isTypeBasicOrPointer(expr1 [expr2]) entonces

GenExprAddress(expr1, temp+1) ||
temp+2 := temp+2 * sizeOfArrayElem(expr1) ||
temp := temp + offsetAux_Space ||
copy temp+1 temp sizeOfArrayElem(expr1) ||
[“ expr1.exprText[temp+2]”, false, Z-CodeList]
sino
temp := temp + temp+1
Figura 6.17 - Generación del Z-Code para el acceso a un elemento de una array
El resultado de los accesos a arrays son iguales a los de campos de struct. En ambos
casos son de la forma expr1 [expr2].
A la hora de generar el código, también nos basaremos en el tipo de los elementos del
array y de si es referenciable. Siempre deberemos calcular el valor del índice del array

(expr2) y el valor o dirección de expr1, según corresponda. A continuación, debemos

calcular el desplazamiento motivado por el índice y finalmente, acceder al valor.
6.3.2.1.7. Llamada a Función
GenExprValue ( ident (expr1, expr2,…,exprN), temp) :

pushResult
para cada expri hacer

si isParamRef(expri) entonces GenExprAddress(expri, temp)
sino GenExprValue(expri, temp)
push expri.exprText
fpara
GenStaticLink(ident, temp)
call ident
pop
fpara
popResult(temp)
Figura 6.18 - Generación del Z-Code para una llamada a función
La primera instrucción de la llamada a una función se corresponde con la reserva de

espacio para el resultado que retornará. En el patrón anterior esto viene indicado por la
llamada a pushResult, función que ya hemos definido.
A continuación, en función de que estemos tratando con un parámetro por valor o por
referencia, generaremos el código para pasarlo tal y como toque. Es decir, si tenemos
que pasar un parámetro por valor, llamaremos a GenExprValue y si es por referencia a
GenExprAddress. Se pasará a guardar en pila en resultado retornado por estas funciones.
El siguiente paso es encargarse de generar las indirecciones necesarias a partir del

static_link para llegar a la definición de la función que vamos a llamar.
Finalmente, restauraremos la pila al estado de antes de la llamada. A efectos prácticos,

liberaremos tanto espacio como hemos reservado para los parámetros que hemos pasado
a la llamada. Es decir, tendremos tantos push como pop.

El último paso es devolver el resultado. El espacio de este resultado ha sido reservado al

principio, ahora tan sólo tenemos que extraer la información guardada en ese espacio
para obtener el resultado. Este paso aparece implementado en la función popResult
definida anteriormente.
6.3.2.1.8. Acceso a lo Apuntado por un Puntero
GenExprValue (expr^, temp) :

GenExprValue(expr, temp)
si levelsDiff(expr) = 0 entonces
si expr.exprNuclear entonces
[“*expr.exprText”, false, Z-CodeList]
sino
temp := expr.exprText
sino
temp := expr.exprText
Figura 6.19 - Generación del Z-Code de acceso al valor apuntado por un puntero
Para acceder al valor apuntado por un puntero, hemos de calcular primero el valor de la
expresión mediante una llamada a GenExprValue. Después, en función del nivel en el
que está definida la expresión y de si es nuclear o no, actuaremos de una u otra manera.
6.3.2.1.9. Dirección de una Expresión
GenExprAddress(&expr, temp) :
si expr.exprNuclear [“&expr.exprText”, false, Z-CodeList]
sino
Figura 6.20 - Generación del Z-Code de la dirección de una expresión

El cálculo del valor de la dirección de una expresión se realiza mediante una llamada a
GenExprAddress. Según si el string que devuelve esta función es nuclear o no, el
resultado final será uno u otro.
6.3.2.2. Generación de la Dirección de Expresiones
6.3.2.2.1. Identificadores
GenExprAddress(IDENT, temp) :
si isTypeBasic(IDENT) && !isTypePointer(IDENT) entonces
si isVarLocal(IDENT) entonces  [“IDENT.text”, true, ]
si isParamRef(IDENT) entonces  [“IDENT.text”, false, ]
si isParamVal(IDENT) entonces
temp := &IDENT.text
 [“temp”, true, Z-CodeList]
sino
GenStaticLink( IDENT, temp)
[“temp”, false, Z-CodeList]
sino si isTypePointer(IDENT) entonces
si isVarLocal(IDENT) entonces [“&IDENT.text”, false, ]
si isParamRef(IDENT) entonces [“IDENT.text”, true, ]
si isParamVal(IDENT) entonces
temp := &IDENT.text
 [“temp”, true, Z-CodeList]
sino
Figura 6.21 - Generación del Z-Code de la dirección de un identificador

sino
si isVarLocal(IDENT) entonces [“&IDENT.text”, true, ]
si isParamRef(IDENT) entonces [ “IDENT.text”,false, ]
si isParamVal(IDENT) entonces [“IDENT.text”, false, ]
sino
[“temp”, false, Z-CodeList]
Figura 6.22 - Generación del Z-Code de la dirección de un identificador (II)
La generación del código para el cálculo de la dirección de un identificador es muy

similar al del valor de un identificador. A efectos prácticos, la diferencia está en que
para el caso del valor, hemos de realizar una indirección de más sobre el identificador
para cargar el valor.
6.3.2.2.2. Acceso al campo de un Struct
GenExprAddress(expr.IDENT, temp) :
si isTypeBasicOrPointer(IDENT) entonces
sino !isTypeBasicOrPointer(IDENT) entonces

temp+1 := temp + offsetField(expr, IDENT) ||
temp := temp + auxSpaceOffset ||
copy temp+1 temp sizeOf(expr.IDENT)
si expr.isExprNuclear
sino
[“expr.exprText[offsetField(temp)]”, false, Z-CodeList]
Figura 6.23 - Generación del Z-Code de la dirección del campo de un struct

El patrón definido es muy similar a su análogo para el caso del valor. El resultado final
acaba siendo un string de la forma expr1[expr2], donde expr2 indica el desplazamiento
hasta el campo del struct.
6.3.2.2.3. Acceso Elemento de una Array
La dirección de un elemento de un array se calcula de forma muy similar al caso

de calcular el valor, pero aquí hay mucho menos casuística que contemplar puesto que
no nos importa el tipo de los elementos del array ni si es referenciable o no.
GenExprAddress(expr1[expr2], temp) :
si isTypeBasicOrPointer(expr1[expr2]) entonces
temp+1 := temp+1 * sizeOfArrayElem(expr1)
[“expr1.exprText[temp+1]”, false, Z-CodeList]
Figura
sino 6.24 - Generación del Z-Code de la dirección de entonces
si !isTypeBasicOrPointer(expr1[expr2]) un elemento de un array
El resultado final, también es del tipo expr1[expr2] con expr2 indicando el
GenExprValue(expr2,
desplazamiento hasta el elemento. temp+2) ||
6.3.2.2.4. temp := &aux_space

Acceso a lo Apuntado por un Puntero
temp := temp + offsetAux_Space
copy temp+1 temp sizeOfArrayElem(expr1)

GenExprAddress(expr^, temp) :
[“ expr1.exprText[temp+2]”,
GenExprValue(expr, temp) || false, T-CodeList]
si levelsDiff(expr) = 0 entonces
si expr.exprNuclear entonces
[“expr.exprText”, false, Z-CodeList]
sino
[“*temp”, true, Z-CodeList]
sino
Figura 6.25 - Generación en Z-Code de la dirección de elementos apuntados

6.3.2.3. Generación de Instrucciones
6.3.2.3.1. Sentencias If
 GenZ-CodeInstruction(if expr1 then l_instrs) :

temp := expr1.exprText ||
if !temp goto endif_label ||
GenZ-CodeInstruction(l_instrs) ||
endif_label:
[Z-CodeList]
 GenZ-CodeInstruction(if expr1 then l_instrs1 else l_instrs2) :

if !temp goto else_label ||
GenZ-CodeInstruction(l_instrs1) ||
goto endif_label ||
else_label: ||
GenZ-CodeInstruction(l_instrs2) ||
endif_label:
[Z-CodeList]
Figura 6.26 - Generación del Z-Code para instrucciones if
Existen dos tipos de sentencias if, las que contienen la alternativa else y las que no. La
generación del código es igual en ambos casos hasta el punto en el que se genera el
código de la alternativa else.

6.3.2.3.2. Sentencias While
 GenZ-CodeInstruction(while expr do l_instrs) :

while_label:
temp := expr.exprText ||
if !temp goto endwhile_label ||
GenZ-CodeInstruction(l_instrs) ||
goto while_label ||
endwhile_label:
[Z-CodeList]
Figura 6.27 - Generación del Z-Code para instrucciones while
El código de una sentencia while es muy similar al de las sentencias if ; de hecho, la

traducción incorpora una sentencia if.
6.3.2.3.3. Instrucción de Lectura
GenZ-CodeInstruction(read expr) :
read expr.exprText
[Z-CodeList]
Figura 6.28 - Generación del Z-Code para una instrucción de lectura
Read es una instrucción que lee de línea de comandos y almacena lo leído en la

expresión expr. Para ello, generamos la dirección de esa expresión.

6.3.2.3.4. Instrucciones de Escritura
 GenZ-CodeInstruction(write expr) :
si isTypeString(expr) entonces wris expr.exprText
sino
wrii expr.exprText
[Z-CodeList]
 GenZ-CodeInstruction(writeln expr) :
si isTypeString(expr) entonces wris expr.exprText ||
wrln
sino
wrii expr.exprText ||
wrln
[Z-CodeList]
Figura 6.29 - Generación del Z-Code para una instrucción de escritura
La diferencia entre ambas instrucciones de escritura es que writeln introduce un salto

de línea.
En ambos casos, hay que diferenciar en si escribimos el valor de una expresión o un

string introducido directamente en la instrucción. Para el caso de la instrucción, hemos
de generar el valor de esa expresión.

6.3.2.3.5. Llamada a procedimiento
GenZ-CodeInstruction ( ident (expr1, expr2,…,exprN), temp) :

si isParamRef(expri) entonces GenExprAddress(expri, temp)
sino GenExprValue(expri, temp)
push expri.exprText
fpara
GenStaticLink(ident, temp)
call ident
pop
fpara
[Z-CodeList]
Figura 6.30 - Generación del Z-Code para llamadas a procedimiento
Las llamadas a procedimientos se traducen de igual manera que las llamadas a

funciones. La diferencia es que no hace falta reservar y posteriormente liberar espacio
para el resultado.
6.3.2.3.6. Operaciones de Punteros
 GenZ-CodeInstruction(new expr) :
new expr.exprText
[Z-CodeList]
 GenZ-CodeInstruction(free expr) :
free expr.exprText
[Z-CodeList]
Figura 6.31 - Generación del Z-Code para instrucciones de punteros (new y free)

New y free son instrucciones que trabajan con punteros. New se encarga de reservar
espacio para la expresión expr. Free se encarga de liberar el espacio reservado por new
para esa expresión.
6.3.2.3.7. Asignación
GenZ-CodeInstruction ( expr1 := expr2, temp) :

si isTypeBasicOrPointer(expr1 := expr2) entonces
si ! expr1.exprNuclear && ! expr2.exprNuclear entonces
expr1.exprText := temp
sino
expr1.exprText := expr2.exprText
sino si !isTypeBasicOrPointer(expr1:= expr2) && isRef(expr2) entonces
GenExprAddress(expr2, temp+2) ||
copy expr2.exprText expr1.exprText sizeOf(expr1)
sino si !isTypeBasicOrPointer(expr1:= expr2) && !isRef(expr2) entonces

copy expr2.exprText expr1.exprText sizeOf(expr1)
[Z-CodeList]
Figura 6.32 - Generación del Z-Code para la instrucción de asignación
La asignación es el tipo de instrucciones más importantes y más abundante en Z-Code.
Para traducir las asignaciones de CL a Z-Code, deberemos de considerar el tipo de las

expresiones a asignar y si la expresión de la parte izquierda es referenciable.
En función de estas dos cosas, deberemos generar la dirección o valor de las expr1 y
expr2. Si el tipo de las expresiones no es básico, deberemos realizar una copia usando el
aux_space.

Hasta el momento hemos visto los patrones de traducción usados para traducir del
lenguaje CL al lenguaje Z-Code. Para finalizar con la traducción de CL a Z-Code
veremos tres funciones auxiliares de las cuales se hace uso en varios de los patrones
mostrados a lo largo de este apartado.
Definiremos las siguientes tres funciones auxiliares:
GenStaticLink( ident, temp) :

temp := static_link ||
(temp := * temp)n-1||
temp := temp + offset(IDENT)
Figura 6.33 - Generación del Z-Code para calcular el static_link
La instrucción (temp := * temp)n-1, indica que realizaremos esta acción n-1 veces
siendo n el número de saltos hasta llegar al ámbito donde ha sido declarada la variable
o el parámetro ident.
popResult (temp):
top temp ||
pop
Figura 6.34 - Generación del Z-Code de recogida de resultados para llamadas a funciones
pushResult:
si isTypeBasicOrPointer( returnType(ident) ) entonces push 0
sino
temp := temp + offsetAux_Space ||
push temp
Figura 6.35 - Generación del Z-Code de reserva de espacio para el resultado de funciones
Si siguiéramos el orden de fases de un compilador habitual, la siguiente consistiría en

generar una representación intermedia en Z-Code, pero esta vez optimizada. Como ya se
ha comentado varias veces a lo largo de este documento, en este proyecto no se
considera la optimización y por tanto, veremos directamente la generación de código

ensamblador.
6.3.3. Etapa de Síntesis de Generación de Código

Ensamblador o Back-end
Aquí trataremos la última parte del compilador desarrollada en este proyecto, la
etapa de Back-end. A pesar de que esta etapa comprende dos fases, Generación de
Código Objeto y Optimización de Código Objeto, en este proyecto sólo se ha tratado la
fase de Generación de Código puesto que, igual que ocurre con la representación
intermedia, la optimización no ha sido objeto de nuestro estudio.
Así pues, en la fase que se presenta a continuación veremos cómo se ha llevado a cabo
la traducción al lenguaje ensamblador IA-32, para arquitectura Intel.
6.3.3.1. Fase de la Generación de Código Ensamblador
La generación de código ensamblador ha requerido de diferentes tareas:
 Reconocimiento del lenguaje Z-Code. Para poder reconocer el lenguaje Z-Code,

ha sido necesario implementar una gramática que lo defina de igual manera que
hicimos en su momento con el lenguaje CL. Esto ha sido así porque se ha
querido asegurar la corrección sintáctica del programa traducido a Z-Code,
aunque no es realmente necesario.
 Implementación de la representación interna de Z-Code. Esta tarea realiza la

traducción del código intermedio Z-Code a una nueva estructura de datos que
utilizará el traductor propiamente dicho.
 Traducción a código ensamblador. La traducción se ha realizado siguiendo

unos patrones similares a los descritos para la generación de Z-Code. Hay que
destacar el hecho de que en esta etapa no se ha utilizado el mecanismo de
StringTemplates que proporciona ANTLR, aunque sí que se podría haber
hecho.
Los archivos utilizados en esta fase son tres:
 ZCode.g: contiene la gramática y tokens que definen el lenguaje Z-Code.
 ZCode.java: esta clase implementa toda la estructura del Z-Code en su

representación interna y realiza comprobaciones necesarias para la traducción a
ensamblador. En esta clase hay definidas diferentes clases como son:
ZCodeInstr, ZCodeOperand y ZCodeSubroutine.

 ZCodeToIA32.java: implementa la clase que genera la traducción de Z-Code a

ensamblador IA32.
Como ya se ha comentado, para poder traducir un programa Z-Code a lenguaje

ensamblador, se ha tenido que crear una representación interna para él. Esta
implementación es necesaria para facilitar el proceso de traducción.
6.3.3.2. Representación Interna de Z-Code
Llevado a programación, un programa de Z-Code se representa como una lista de

instrucciones y un conjunto de información necesaria como son por ejemplo, los
ámbitos, las variables de un ámbito y el offset para llegar a ellas,…, es decir, toda la
información que se necesita para traducir.
Como ya hemos dicho, un programa se representa como un conjunto de instrucciones,

concretamente, como una lista de ZCodeInstr.
Una ZCodeInstr está formada por un token o código de operador que indica la
instrucción que estamos tratando y por tres ZCodeOperand, dado que Z-Code es un
código de tres direcciones y como máximo, tendremos tres operandos.
Un ZCodeOperand se compone de un tipo y texto. El tipo nos indica si se trata de una

etiqueta, un identificador, un temporal, una constante... El texto es la cadena de
caracteres asociada al operando.
Durante el reconocimiento del programa en Z-Code, se guarda información concreta de

cada instrucción. Se trata de pensar en qué es lo que distingue a una instrucción de otra.
En Z-Code existen dos tipos de instrucciones bien diferenciadas:
 Instrucciones de asignación, donde el operador discrimina el tipo de

instrucción.
o operando := operando OPERADOR operando
o operando := OPERADOR operando
o operando := operando (instrucción de copia)
 Instrucciones con una sintaxis tipo ensamblador: COPY, REAI, WRII, WRIS,
WRLN, CALL, STOP, RETU, PUSH, POP, TOP, NEW, FREE.
Las instrucciones tipo ensamblador son fáciles de diferenciar entre sí, puesto que tienen
nombres diferentes. Las instrucciones de tipo asignación las diferenciaremos por el tipo

de operador que utilizan obviando el operador de asignación excepto en el caso de la

copia.
Los operandos de todas las instrucciones se guardan en orden de ocurrencia, es decir,

que para una instrucción como t0 := a + b; t0 es el primer operando, a el segundo y
b el tercero. En las instrucciones de la forma operando := OPERADOR operando,
guardaremos, por simplicidad, el operador como el segundo operando. En este caso
tomaremos la instrucción como una asignación.
Una vez definida la representación interna de Z-Code, se procede a la traducción a

lenguaje ensamblador.
6.3.3.3. Traducción a Lenguaje Ensamblador
El lenguaje ensamblador elegido para la traducción es el IA-32. El motivo

principal de la elección es que es uno de los más comunes. Aún ahora y durante un
tiempo seguirá siéndolo, puesto que los nuevos ordenadores con procesadores de 64
bits, siguen permitiendo la ejecución en modo compatible con IA-32.
IA-32 (Intel Architecture, 32-bit) es la arquitectura que define el conjunto de

instrucciones para la familia de microprocesadores Intel instalados en la gran mayoría
de ordenadores del mundo.
La definición detallada del conjunto de instrucciones de IA-32 más habituales puede

verse en el Anexo Subconjunto de Instrucciones de IA-32.
La traducción a IA-32 se ha realizado siguiendo unos patrones según tipo de

instrucciones, igual que se hizo para Z-Code. La implementación esta vez ha sido más
sencilla debido a que el nivel de abstracción en el punto en el que nos encontramos ha
sido menor.
Antes de ver algunos ejemplos de traducción, analizaremos una de las cuestiones más
importantes, el mapeo de los registros temporales de Z-Code a registros físicos. Sólo se
han llevado a registros físicos los registros temporales de Z-Code y no variables. En Z-
Code existen un número ilimitado de temporales, pero a nivel de ensamblador, los
temporales ya no pueden existir puesto que todo dato debe estar ubicado en memoria o
en registros. El problema es que IA-32 tan sólo cuenta con ocho registros: eax, ebx, ecx,
edx, edi, esi, ebp y esp.
ebp es el base pointer, es decir, el puntero al inicio de la pila actual mientras que esp, es
el puntero a la posición actual de la pila. Por lo tanto, como podemos apreciar, en
realidad sólo contamos con seis registros donde poder almacenar datos.
A la hora de mapear los temporales, hemos de seguir un criterio. Algunos de los que nos
podemos plantear son:

 Mapeo directo de los temporales a registros, es decir, cada temporal se

corresponde con un registro. Si llega un momento en que el número de
temporales usados es mayor que el número de registros libres, esos temporales
se mapean en memoria.
 Asignación de los temporales a registros libres, es decir, la correspondencia

temporal-registro no es fija, ya que se calculará en cada momento cuál es el
registro libre para asignar. Esta es la opción más eficiente de todas.
 Mapeo de temporales en memoria. Esta alternativa es la menos óptima puesto

que los procesadores trabajan de manera más eficiente con los registros que con
accesos a memoria.
 …
En este proyecto se ha optado por la primera alternativa principalmente por dos

motivos:
 La simplicidad a la hora de implementarla.
 A pesar de no ser la opción óptima, es una buena alternativa. Hemos de tener en

cuenta que Z-Code ha sido generado de una manera bastante óptima en cuanto
al uso de temporales se refiere. Por lo tanto, a pesar de que pueda llegar el
momento en que haya más temporales que registros a los que asignar, ese
número de temporales no será muy elevado y por consiguiente, no se deberán
de mapear muchos temporales en memoria, hecho que ralentiza la ejecución.
La forma en la que se ha realizado el mapeo de temporales es la siguiente:
 Los registros eax y edx se han reservado para guardar resultados intermedios y
por ser registros destino de algunos cálculos que realiza el procesador como son
multiplicación y división.
 El resto de registros son mapeados de forma directa por algunos temporales:
o t0  ebx
o t1  ecx
o t2  edi
o t3  esi
 A partir del temporal t4, el mapeo se hace en memoria (en la pila de ejecución).
La forma de calcular la posición exacta de memoria asociada a uno de estos
temporales es:

calc = totalSizeOfVars(actualScope)+(numTemp-3)*4;
mem = “-calc(%ebp)";
Figura 6.36 - Cálculo de la posición en memoria para un temporal
La función totalSizeOfVars(actualScope) calcula el tamaño que ocupan en total

todas las variables definidas en el Z-Code en un scope determinado.
numTemp indica el número de temporal que estamos tratando, es decir, que

será un número entero mayor que tres puesto que, como hemos visto, hasta t3
están mapeados en registros. Multiplicamos ese número restándole tres por
cuatro, que es el número de bytes que ocupa un temporal.
Finalmente, la dirección completa de memoria donde se ubicará el temporal es

el desplazamiento calculado anteriormente aplicado al valor del registro ebp.
Es interesante destacar el hecho que en IA-32 una misma instrucción no puede contener
dos accesos a memoria. Los modos de direccionamiento con los que cuenta son:
 Inmediatos. Los inmediatos representan valores constantes y se definen en el

código de la forma $inm.
 Indirecto. Éstos permiten indicar direcciones de memoria a partir de registros y
de inmediatos. Se especifican de la forma inm(%reg) entre otras posibles
alternativas.
 Registros. El uso de registros físicos se define de la forma %reg.
Pasemos ahora a ver un ejemplo de los patrones de traducción aplicados:
translateInstruction( temp := a + b) 
translateOperand(op1, temp) ||
translateOperand(op2, a) ||
translateOperand(op3, b) ||
addl op2, op3 ||
movl op3, op1
Figura 6.37 - Ejemplo de aplicación de patrones

translateInstruction( temp := temp+1 + temp+2) 

translateOperand(op1, temp) ||
translateOperand(op2, temp+1) ||
translateOperand(op3, temp+2) ||
movl op2, %eax ||
movl op3, %edx ||
addl %eax, %edx ||
movl %edx, op1
Figura 6.38 - Ejemplo de aplicación de patrones (II)
Ambos patrones se utilizan para generar el código ensamblador de las instrucciones de

suma, pero son aplicables a muchos más tipos de instrucciones de asignación, siempre y
cuando cambiemos la instrucción addl por el correspondiente operador.
La diferencia entre los patrones es que en uno, los operandos son temporales mientras
que en el otro no. El hecho que los operandos sean temporales obliga a tener que cargar
primero el valor, por si se diera el caso que esos temporales han sido mapeados en
memoria.
Algo que es interesante remarcar en este punto es que a nivel de lenguaje ensamblador,
los desplazamientos de memoria son negativos. Si recordamos, en el capítulo 3,
tomamos como convención de notación que los desplazamientos eran positivos para
facilitar la comprensión. Así pues, veamos ahora cómo es realmente la gestión de
memoria y la activación de los bloques:

Figura 6.39 - Pila en ejecución
Como podemos observar esta imagen es justo la inversa a la otra mencionada. Por ello,
debemos interpretar que el valor retornado está en posiciones de memoria más altas que,
por ejemplo lo están las variables locales.
La función de translateOperand(op) se encarga de traducir los operandos según el tipo

que son. En este nivel los tipos de operando que podemos encontrar son básicamente:
 Temporales. Ya se ha explicado antes qué criterio se sigue para su traducción.
 Identificador. Los identificadores se encuentran en una posición de memoria de

la forma: offset(%ebp). El offset es el desplazamiento respecto del base
pointer que hay en pila hasta llegar al identificador en cuestión. Pero
previamente hay que llegar hasta el bloque de activación donde se encuentra el
identificador siguiendo la cadena de static_links.
 Constante. Si estamos tratando con una constante, tan sólo devolveremos el

valor de la constante como un string precedido del símbolo “$” usado siempre
en IA-32 en las constantes.

 Offset. El offset es un entero que indica desplazamientos. La traducción será

igual que la de una constante. Se trata de un valor positivo para los parámetros
y negativo para las variables locales, ya que el ebp apunta al static_link.
 ReturnValue. Éste es el valor que retornan las funciones. Hay un espacio en pila
reservado para él. Se accede de forma similar a los parametros del
procedimiento
 Static_link. El static_link apunta al bloque de activación del padre estático. Es

un dato calculado y colocado por el procedimiento o función que realiza la
llamada, al igual que los parámetros actuales. Una vez comienza a ejecutarse la
subrutina llamada, el registro %ebp apunta a la posición de memoria donde se
encuentra el static_link para poder seguir de una forma sencilla la cadena de
indirecciones que conducen a los bloques de activación de los sucesivos
ancestros.
 Aux_space. Es una situación similar a la de las variables locales. Aux_space es

un espacio de memoria definido por el compilador y, por tanto, en este punto
tan sólo se trata de encontrar el desplazamiento en pila necesario para acceder a
él.
 Etiquetas. Las etiquetas se traducen como simples strings, que es lo que ya son
en Z-Code.
A la hora de traducir a IA-32 hemos de tener en cuenta muchos otros conceptos. En

ensamblador, no existen diferentes ámbitos, sino que existe un único ámbito global de
todo el programa. Por ejemplo, todas las etiquetas deben ser ahora diferentes, aunque en
Z-Code se permitan diferentes etiquetas endif_: en diferentes subrutinas.
Además, existe un patrón genérico de traducción de cómo debe ser un programa en

ensamblador. Todos los programas IA-32 deben empezar de la siguiente manera:

.section .data
.section .rodata
/* INICIO PARTE OPCIONAL */
. comm res_reai, 4
.FMTwris:
.string %s
.FMTwrln:
.string \n
.FMTwrii:
.string %d
.FMTreai:
.string %d
.STRwrts_i:
.string CONST
/* FIN PARTE OPCIONAL */
.section .text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
call program
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.globl program
.type program, @function
program:
pushl %ebp
movl %esp, %ebp
subl $varsSize, %esp
Figura 6.40 - Patrón genérico de traducción a IA-32
La parte indicada como opcional es el código correspondiente a las instrucciones de

read, write y writeln de CL. Por lo tanto, si en un código en concreto no existen estas
instrucciones, ese código no aparecerá en la traducción.
Las primeras instrucciones del main, hasta la llamada a program, se encargan de

preparar la pila y los registros antes de llamar al programa principal del Z-Code
(función program).

Capítulo 7. Planificación y Costes del Proyecto
7. Planificación y Costes del Proyecto

En este capítulo se describirán la planificación y los costes del proyecto. Se
mostrará la planificación inicial estimada antes de empezar la realización del proyecto y
posteriormente, se mostrará la duración real de las tareas realizadas.
A partir de la duración real de las tareas llevadas a cabo, se podrá estimar un coste total
aproximado del proyecto.
7.1. Planificación Inicial del Proyecto

Este proyecto se inició en Octubre de 2009 y se finaliza en Julio de 2011. La
dedicación al proyecto ha sido parcial durante los meses de Octubre de 2009 a Junio de
2010 y en ocasiones se ha pospuesto a periodos vacacionales, puesto que se ha llevado
a cabo a la vez que cursaba otros estudios y trabajaba.
Antes de iniciar el proyecto, se realizó un esquema de las tareas a realizar, que

posteriormente se han ido modificando y ampliando. A partir de las tareas se estimó una
duración inicial.
Veamos las tareas que se han llevado a cabo, divididas en tres grandes grupos:
 Ampliación del lenguaje CL.
o Diseño de la ampliación del lenguaje CL
o Implementación del compilador que integra las ampliaciones del

lenguaje CL
- Modificación de la fase de Análisis Léxico
- Modificación de la fase de Análisis Sintáctico
- Modificación de la fase de Análisis Semántico
 Diseño y generación de código intermedio.
o Definición del código intermedio Z-Code

o Diseño de los patrones de traducción a Z-Code
o Implementación de la fase de traducción a Z-Code
 Diseño de la traducción y generación de código ensamblador.
o Diseño de los esquemas de traducción a IA-32
o Implementación de la traducción a IA-32

Además de las tareas propias del proyecto, antes de empezar con su desarrollo, se
realizó un estudio de las nuevas herramientas a utilizar que proporciona ANTLR v3 y
del estado en el que se encontraba el trabajo, puesto que como ya se ha comentado en
varias ocasiones, el proyecto partía de un trabajo ya existente.
A continuación se muestra el diagrama de Gantt correspondiente a la planificación

inicial del proyecto.

Figura 7.1 - Planificación inicial del proyecto

7.2. Duración Real del Proyecto

El siguiente diagrama de Gantt muestra la duración real de todas las tareas desarrolladas.
Figura 7.2 - Duración real del proyecto

7.3. Desviaciones en la Estimación

Tal como se ha comprobado, la estimación de la duración del proyecto difiere de
la real.
En general las tareas han requerido mayor duración, sobre todo las que se refieren al
segundo grupo, Diseño de la traducción y generación de código intermedio. La
definición del lenguaje Z-Code y la traducción hasta él han necesitado una gran
dedicación, puesto que fallos en esta parte provocarían errores de difícil corrección una
vez se hubiera finalizado la etapa.
Las desviaciones en el tiempo han tenido diversas causas:
 Dificultades encontradas durante el desarrollo de algunas partes

 Falta de experiencia en la planificación de proyectos
Aparte de las causas anteriores, principalmente, la finalización del proyecto se ha visto
afectada por la falta de tiempo, lo cual no ha modificado la duración estimada de las
tareas pero sí que ha desplazado el momento de finalización del proyecto.
7.4. Cálculo de Costes del Proyecto

Para el cálculo de costes será necesario dividir las tareas del proyecto por perfiles
necesarios para su realización, aunque el proyecto haya sido realizado por una única
persona. El objetivo es obtener una estimación del coste que podría tener el proyecto en
un ámbito empresarial con unos sueldos similares a los reales.
Asumiremos dos perfiles claramente diferenciados en este proyecto:
 Analista. El analista es el perfil encargado de las tareas relacionadas

principalmente con el diseño y la definición. Se estima que el sueldo de un
analista es de 50 euros/hora.
 Programador. Este perfil es el que se encarga de implementar los diseños
especificados por el analista. Se estima que el sueldo base de un programador es
de 30 euros/hora.
A la hora de calcular los costes de este proyecto en un ámbito empresarial se deberían
de tener en cuenta muchos más costes como por ejemplo, los recursos utilizados:
ordenador, gastos relacionados con software,... A pesar de ello, para el cálculo que
presentaremos aquí no se considera necesario puesto que el propio tema del proyecto no
tiene una visión empresarial.

Suponiendo que el trabajo realizado ha sido llevado a cabo en jornadas con un promedio
de dos horas y media diarias, el total de horas imputables al proyecto son:
351 días x 2.5 horas/día = 877.5 horas
Figura 7.3 - Total horas dedicadas al proyecto
Veamos ahora la relación de esas tareas con el perfil que las ha realizado:
Figura 7.4 - Perfiles desarrolladores de las tareas del proyecto
De la figura anterior se pueden extraer el número de horas dedicadas por cada perfil:
 Analista.
o 170 días x 2.5 horas/día = 425 horas.
o 425 horas x 50 euros/hora = 21.250 euros
 Programador.
o 181 días x 2.5 horas/día = 452.5 horas.
o 452.5 horas x 30 euros/hora = 13.575 euros

Así pues, el coste total del proyecto es:
21.250 + 13.575 = 34.825 euros
Figura 7.5 - Coste total del proyecto

Capítulo 8. Conclusiones y Trabajos Futuros
8. Conclusiones y Trabajos Futuros

8.1. Conclusiones
A lo largo de este documento se ha estudiado en detalle el funcionamiento de
cada una de las etapas del compilador y se ha mostrado la implementación de un
compilador para el lenguaje de alto nivel CL utilizando para ello la nueva herramienta
de desarrollo de compiladores ANTLR v3.
Como bien se comentó en el capítulo 1, el principal objetivo del proyecto ha sido

construir un mejor compilador de CL en cuanto a potencia del lenguaje que reconoce,
eficiencia y legibilidad del código de la representación intermedia. Además, finalmente,
este compilador debe generar el código ensamblador para que cualquier programa
fuente reconocido pueda ser ejecutado en la arquitectura IA-32.
Una vez concluido el proyecto podemos decir que este objetivo se ha cumplido
totalmente, ya que:
 Potencia del lenguaje reconocido. Se ha conseguido una ampliación del

lenguaje CL con la gestión de memoria dinámica y los tipos definidos por el
usuario, permitiendo la compilación de un mayor número de programas.
 Eficiencia en la compilación. Dado que la nueva representación intermedia en Z-
Code generada conlleva un menor número de instrucciones que la representación
usada anteriormente, podemos decir que el resultado de la compilación es más
eficiente temporal y espacialmente. Temporalmente dado que existe un menor
número de instrucciones y, espacialmente debido que al haber un menor número
de instrucciones, éstas ocupan un espacio menor en memoria.
 Legibilidad de la representación intermedia. La representación intermedia Z-
Code se ha definido pensando siempre en obtener traducciones más legibles y
comprensibles por el usuario. De ahí, que se haya optado por una representación
intermedia bastante próxima al alto nivel reduciendo también el número de
instrucciones generadas por la traducción.
 Ejecución de los programas en la arquitectura IA-32. Se ha realizado una
traducción a lenguaje ensamblador IA-32 que garantiza que todo programa
correcto escrito en el lenguaje fuente CL, puede ser ejecutado en máquinas con
arquitectura IA-32.
Además, no se debe de olvidar la importancia que ha tenido el uso de la herramienta

ANTLR v3 durante el desarrollo del proyecto, puesto que forma parte del objetivo
marcado.

La consecución de los objetivos y por tanto, la realización de este proyecto,

personalmente me ha aportado nuevos e importantes conocimientos entre los que cabe
destacar:
 Definición gramatical de lenguajes. El diseño y definición del lenguaje Z-Code
me ha permitido aprender a diseñar gramaticalmente nuevos lenguajes desde
cero, trabajo muy importante para el desarrollo de compiladores y en concreto,
de la representación intermedia.
 Desarrollo de software con módulos previamente implementados. Otro de los

importantes aprendizajes llevados a cabo durante la realización de este proyecto
ha sido el de trabajar con un código que ya contaba con partes implementadas
por otras personas.
Esta ha sido la primera vez que he empezado un trabajo a partir de algo que
alguien ya había previamente desarrollado, teniendo que modificarlo y
ampliarlo. Esta experiencia conlleva un aprendizaje muy importante, ya que es
necesario comprender el trabajo existente antes de continuar. Además, ha sido
muy útil poner en práctica esta forma de trabajo puesto que es la más habitual
hoy en día, sobre todo en lo que se refiere al entorno empresarial.
 Estudio de una nueva versión ANTLR v3. Previamente ya había trabajado con
versiones anteriores de ANTLR, pero la implementación de este compilador me
ha permitido, por un lado, profundizar mucho más en la herramienta ANTLR y
por otro, poner en práctica los nuevos mecanismos que ofrece, Parsing LL(*) y
StringTemplates.
 Ampliar los conocimientos de IA-32. A pesar de que previamente también había
hecho uso del lenguaje ensamblador IA-32 en algunas asignaturas de la carrera,
nunca lo había llevado a una aplicación tan real como esta. Esto me ha
permitido profundizar mucho más en mis conocimientos sobre el lenguaje para
la arquitectura IA-32 y sobre el formato de cómo deben de ser sus ficheros.
 Ampliar el conocimiento general sobre compiladores. Finalmente, y muy

importante ha sido la ampliación de conocimientos sobre los compiladores.
Aunque en la asignatura de Compiladores ya se obtienen importantes
conocimientos al respecto, el desarrollar prácticamente todas las etapas de un
compilador desde cero me ha permitido obtener una visión más global de ellos.
Pero, también he profundizado más en temas como las etapas de Middle-end y
Back-end.
A modo de conclusión personal considero que este proyecto me ha permitido

profundizar en general en todos los aspectos de un compilador pero, especialmente,
en aquellos que desde que realicé la asignatura de Compiladores más me llamaron la
atención.

8.2. Trabajos Futuros

En este apartado se describirán algunos de los posibles trabajos futuros que se
pueden realizar a partir de este proyecto.
Todas las alternativas presentadas se basan bien en ampliaciones, en mejoras del trabajo
ya realizado o en alternativas de implementación. Aunque mayoritariamente están
relacionadas con la fase de optimización de la representación en Z-Code, ya que como
se ha comentado, en este proyecto no se ha tratado estrictamente esta fase por no ser el
objeto de estudio, pero sí que es importante tener en cuenta que hoy en día es una de las
características más interesantes y deseables de un compilador.
A continuación desglosaremos estos trabajos según se refieran a ampliaciones o a

mejoras.
 Ampliaciones sobre el trabajo realizado

o Ampliación del lenguaje CL. Se puede desear ampliar el lenguaje CL de
muchas maneras, introduciendo por ejemplo, la orientación a objetos,
coerción de tipos, gestión de excepciones,...Esta ampliación implicaría
modificar todas las etapas del compilador de igual manera que ocurrió
con la gestión de memoria dinámica y los tipos definidos por el usuario.
o Diseño de un Back-end alternativo que permita la traducción para la
arquitectura IA-64. De esta forma el usuario del compilador puede
especificar cuál es el código objeto de la compilación.
 Mejoras sobre el trabajo realizado
o Aplicar mecanismos de optimización independientes de la arquitectura.

La optimización de la representación intermedia una vez generada es una
de las cuestiones más importantes hoy en día en un compilador. Las
optimizaciones independientes de la arquitectura, realizadas después de
la generación de código Z-Code permitirían un código resultado de la
compilación más eficiente y por tanto, serían un importante punto de
estudio para un trabajo futuro.
o Aplicar mecanismos de optimización dependientes de la arquitectura. De

igual manera que se podrían estudiar las optimizaciones independientes,
se podrían hacer con las dependientes de la arquitectura trabajando a
nivel de código ensamblador.
o Optimización de la generación del Z-Code. Ésta se refiere a las propias

optimizaciones que se pueden realizar a la hora de generar el código
intermedio Z-Code. Como bien se ha comentado en otros capítulos de
este documento, la generación de Z-Code realizada está muy optimizada,

pero aún podría ser mejor, por ejemplo, estudiando en mayor detalle el
uso de registros temporales.
o Optimización de la generación del IA-32. La generación de IA-32 podría

ser más óptima en cuanto al uso de registros físicos de la arquitectura y
de las subsecuencias de instrucciones generadas.
 Alternativas de implementación
o Aplicación de StringTemplates para la generación de código IA-32.

Como ya se ha comentado, para la generación de Z-Code se hizo uso de
StringTemplates. Esto mismo se puede llevar a cabo para la generación
del código IA-32.
Así pues, durante la realización del proyecto se ha tenido constancia de las posibles
ampliaciones, mejoras o alternativas de implementación con la idea de que sean
llevadas a cabo en futuros trabajos siendo este proyecto una buena base para empezar.

Capítulo 9. Acrónimos
9. Acrónimos
Acrónimo Descripción
ANTLR ANother Tool for Language Recognition
AST Abstract Syntax Tree
BNF Backus–Naur Form
BP Base Pointer
CFG Context-Free Grammar
DFA Deterministic Finite Automaton
EBNF Extended Backus–Naur Form
IA-32 Intel Architecture, 32 bits
LL Left to right, Leftmost derivation
LR Left to right, Rightmost derivation
NDFA Non-Deterministic Finite Automaton
PC Program Counter
PCCTS Purdue Compiler Construction Tool Set
RI Representación Intermedia
SP Stack Pointer

Capítulo 10. Bibliografía
10. Bibliografía
1. Aho, Alfred V., Sethi, Ravi y Ullman, Jeffrey D. Compiladores : principios,
técnicas y herramientas. s.l. : Addison-Wesley Iberoamericana, 1990. 0201629038.
2. Parr, Terence. The Definitive ANTLR Reference: Building Domain-Specific

Languages. s.l. : The Pragmatic Programmers, 2007. 978-0-9787-3925-6.
3. Johnson, Stephen C. Unix Programmer's Manual Vol 2b. Yacc: Yet Another
Compiler-Compiler. [En línea] 1979. http://dinosaur.compilertools.net/yacc/.
4. Bison - GNU parser generator. [En línea] http://www.gnu.org/software/bison/.
5. ANTLR Parser Generator. [En línea] http://www.antlr.org/.
6. Parr, Terrence. Enforcing Strict Model-View Separation in Template Engines. [En

línea] 2004. http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf.
7. LENGUAJES DE PROGRAMACIÓN. [En línea]

http://www.brioazul.com.mx/paginas/informatica/programacion/lenguajes_programacio
n.pdf.
8. Compiladores: Análisis Semántico y Chequeo de Tipos. [En línea]

oscarbonilla.com/courses/compilers/materials/11_Analisis_Semantico.ppt.
9. Mak, Ronald. Writing compilers and interpreters : a software engineering approach

. s.l. : Hoboken, N.J. : Wiley, 2009. 9780470177075.
10. Johnson, Steve. Code Generation. 2005.
11. Rivero, José Miguel. T-Code Generation.
12. Rivero, José Miguel, Godoy, Guillem y Padró, Lluís. Translation from T-Code to
IA32.
13. Wikipedia. [En línea] http://es.wikipedia.org/wiki/Wikipedia:Portada.

Anexo I. Ejemplo del Proceso de Compilación Completo
Anexo I. Ejemplo del Proceso de

Compilación Completo
En este anexo vamos a mostrar todas las etapas del compilador a través de un
programa ejemplo en CL. El programa que utilizaremos es una versión del mergesort,
donde se ha hecho uso de memoria dinámica con el fin de comprobar el buen
funcionamiento del compilador. En la figura inferior se muestra la implementación en
CL de este programa.
program
vars
Res array[10] of int
cont int
aux int
pA array[10] of pointer to int
endvars
procedure mergesort(ref pi array[10] of pointer to int, val start int, val

end int)
vars
i int
size int
mid int
tam int
paux array[10] of pointer to int
endvars
size := end - start
i := 0
while i < 10 do
new(paux[i])
paux[i]^ := pi[i]^
i := i+1
endwhile
if size > 1 then

i := size / 2
mid := start + i
mergesort(paux, start, mid)
mergesort(paux, mid, end)
merge(paux, start, mid, end)
i := 0
while i < 10 do
pi[i]^ := paux[i]^
i := i+1
endwhile
endif
endprocedure
Figura I.1 - Código del mergesort (I)

procedure merge(ref pm array[10] of pointer to int, val start int, val mid
int, val end int)
vars
R array[10] of pointer to int
p1 int
p2 int
aux int
i int
endvars
i := 0
p1 := start
p2 := mid
aux := start
while i < 10 do
new(R[i])
i := i+1
endwhile
i:=0
while i < start do
R[i]^ := pm[i]^
i := i+1
endwhile
while aux < end do
if p1 < mid and p2 < end then
if pm[p1]^ < pm[p2]^ then
R[aux]^ := pm[p1]^
p1 := p1 + 1
else
R[aux]^ := pm[p2]^
p2 := p2 + 1
endif
else
if p1 < mid then
R[aux]^ := pm[p1]^
p1 := p1 + 1
else
R[aux]^ := pm[p2]^
p2 := p2 + 1
endif
endif
aux := aux + 1
endwhile
i := end
while i < 10 do
R[i]^ := pm[i]^
i := i+1
endwhile
i := 0
while i < 10 do
pm[i]^ := R[i]^
i := i+1
endwhile
endprocedure
Figura I.2 - Código del mergesort (II)

cont := 0
while cont < 10 do
read(aux)
Res[cont] := aux
cont := cont + 1
endwhile
cont := 0
while cont < 10 do
new(pA[cont])
pA[cont]^ := Res[cont]
cont := cont + 1
endwhile
writeln("ENTRADA")
cont := 0
while cont < 10 do
writeln(pA[cont]^)
cont := cont + 1
endwhile
mergesort(pA,0,10)
writeln("RESULTADO")
cont := 0
while cont < 10 do
Res[cont] := pA[cont]^
writeln(Res[cont])
cont := cont + 1
endwhile
endprogram
Figura I.3 - Código del mergesort (III)
Para los ejemplos posteriores utilizaremos el trozo de código de la siguiente figura.
if p1 < mid then

R[aux]^ := pm[p1]^
p1 := p1 + 1
else
R[aux]^ := pm[p2]^
p2 := p2 + 1
endif
Figura I.4 - Código del programa en CL para hacer las pruebas
La primera etapa del compilador es la de Parsing. En esta etapa se reconoce la entrada

como una entrada válida para el lenguaje, y se genera de salida el árbol AST. El árbol
AST correspondiente al código de la Figura I.4 es el siguiente:

| + if
| + <
| | + ident(p1)
| | + ident(mid)
| + ListOfInstrs
| | + :=
| | | + ^
| | | | + []
| | | | + ident(R)
| | | | + ident(aux)
| | | + ^
| | | + []
| | | + ident(pm)
| | | + ident(p1)
| | + :=
| | + ident(p1)
| | + '+'
| | + ident(p1)
| | + int_const(1)
| + ListOfInstrs
| + :=
| | + ^
| | | + []
| | | + ident(R)
| | | + ident(aux)
| | + ^
| | + []
| | + ident(pm)
| | + ident(p2)
| + :=
| + ident(p2)
| + '+'
| + ident(p2)
| + int_const(1)
Figura I.5 - Árbol AST correspondiente al código de la Figura I.4
La siguiente etapa del compilador es la del Type Checking, donde se recibe como
entrada el árbol AST generado por la etapa de Parsing, y se decora con la información
relevante para cada nodo del árbol. En la siguiente figura tenemos el mismo árbol de la
Figura I.5 decorado.

| + if
| + < <bool>
| | + ident(p1) <int> [R]
| | + ident(mid) <int> [R]
| + ListOfInstrs
| | + :=
| | | + ^ <int> [R]
| | | | + [] <(pointer int)> [R]
| | | | + ident(R) <(array int_const(10) (pointer int))> [R]
| | | | + ident(aux) <int> [R]
| | | + ^ <int> [R]
| | | + [] <(pointer int)> [R]
| | | + ident(pm) <(array int_const(10) (pointer int))> [R]
| | | + ident(p1) <int> [R]
| | + :=
| | + '+' <int>
| | + int_const(1) <int>
| + ListOfInstrs
| + :=
| | + ^ <int> [R]
| | | + [] <(pointer int)> [R]
| | | + ident(R) <(array int_const(10) (pointer int))> [R]
| | | + ident(aux) <int> [R]
| | + ^ <int> [R]
| | + [] <(pointer int)> [R]
| | + ident(pm) <(array int_const(10) (pointer int))> [R]
| + :=
| + ident(p2) <int> [R]
| + '+' <int>
| + ident(p2) <int> [R]
| + int_const(1) <int>
Figura I.6 - Árbol AST decorado correspondiente al código de la Figura I.4
A partir del árbol decorado, el compilador genera el código intermedio, en nuestro caso
el Z-Code. El Z-Code correspondiente al código de la Figura I.4 es el siguiente:

t0 := p1 < mid
if0 !t0 goto else_3
t1 := aux * 4
t0 := R[t1]
t2 := pm
t3 := p1 * 4
t2 := t2[t3]
t2 := *t2
*t0 := t2
p1 := p1 + 1
goto endif_3
else_3:
t1 := aux * 4
t0 := R[t1]
t2 := pm
t3 := p2 * 4
t2 := t2[t3]
t2 := *t2
*t0 := t2
p2 := p2 + 1
endif_3:
Figura I.7 - Z-Code correspondiente al código de la Figura I.4
La última etapa del compilador es la que convierte el código intermedio Z-Code a un

lenguaje que pueda interpretar la máquina, en nuestro caso IA32. El ejemplo de la
Figura I.1 queda de la siguiente manera:
movl -44(%ebp), %eax

movl 16(%ebp), %edx
cmpl %eax, %edx
setg %dl
andl $0xFF, %edx
movl %edx, %ebx
movl %ebx, %eax
cmpl $0, %eax
je program_merge_else_3
movl $4, %edx
imull %edx , %eax
movl %eax, %ecx
movl %ecx , %edx
addl %eax, %edx
movl 0(%edx), %edx
movl %edx, %ebx
Figura I.8 - Representación en IA32 del código de la Figura I.4 (I)

movl 24(%ebp), %edx

movl %edx, %edi
movl $4, %edx
imull %edx , %eax
movl %eax, %esi
movl %edi, %eax
movl %esi , %edx
addl %eax, %edx
movl 0(%edx), %edx
movl %edx, %edi
movl 0(%edi), %eax
movl %eax, %edi
movl %edi, %edx
movl %edx, 0(%ebx)
movl $1, %edx
addl %eax, %edx
movl %edx, -44(%ebp)
jmp program_merge_endif_3
program_merge_else_3:
movl $4, %edx
imull %edx , %eax
movl %eax, %ecx
movl %ecx , %edx
addl %eax, %edx
movl 0(%edx), %edx
movl %edx, %ebx
movl 24(%ebp), %edx
movl %edx, %edi
movl $4, %edx
imull %edx , %eax
movl %eax, %esi
movl %edi, %eax
movl %esi , %edx
addl %eax, %edx
movl 0(%edx), %edx
movl %edx, %edi
movl 0(%edi), %eax
movl %eax, %edi
movl %edi, %edx
movl %edx, 0(%ebx)
movl $1, %edx
addl %eax, %edx
movl %edx, -48(%ebp)
program_merge_endif_3:
Figura I.9 - Representación en IA32 del código de la Figura I.4 (II)

Compilación de programa con errores

En las figuras anteriores se ha visto el ejemplo de compilación para un programa fuente
correcto. Pero, un compilador también debe ser capaz de detectar errores. Es por ello
que a continuación se muestran posibles errores en el programa mergesort y cómo
informa de ellos el compilador al programador.
Por ejemplo, en caso de cometer un error sintáctico al programar (por ejemplo, no poner
el símbolo “:=” en una asignación) como en la Figura I.10, el compilador lo detecta y
envía el aviso de la Figura I.11 al programador.
size := end - start

i = 0
while i < 10 do
new(paux[i])
paux[i]^ := pi[i]^
i := i+1
endwhile
Figura I.10 - Ejemplo de código con error sintáctico
Parser threw exceptions -- see output
Figura I.11 - Salida del compilador para un error sintáctico
Otro error típico que se comete en la programación es asignar dos variables de tipo
incorrecto. Esto es lo que sucede en el ejemplo de la Figura I.12. En este caso, la salida
del compilador sería la de la Figura I.13.
size := end - start

i := 0
while i < 10 do
new(paux[i])
paux[i]^ := pi[i]
i := i+1
endwhile
Figura I.12 - Ejemplo de código con error semántico
L. 21:11: Assigment with incompatible types.

Type checking: 1 semantic errors has been found.
Figura I.13 - Salida del compilador para un error semántico

Anexo II. Subconjunto de Instrucciones de IA-32
Anexo II. Subconjunto de Instrucciones de

IA-32
En este anexo se detalla un subconjunto de las instrucciones más importantes y

usadas para la generación de código ensamblador IA-32.
Definiremos la siguiente nomenclatura para poder describir de manera más clara las
instrucciones:
 %reg se refiere al valor de un registro

 inm, denota una constante numérica. En IA-32 para referirnos a los inmediatos
se usa el símbolo “$” delante.
 mem se usa para referirnos a una posición de memoria.
Dividiremos la definición de las instrucciones según su funcionalidad.
1. Instrucciones de movimiento de datos

INSTRUCCIÓN DESCRIPCIÓN
MOV %regA, %regB
MOV $inm, %reg
MOV mem, %reg La instrucción de mover recibe dos operandos y mueve el
MOV %reg, mem primero al lugar donde indica el segundo.
MOV $inm, mem
2. Instrucción de carga sobre la pila

PUSH %reg El procesador toma el valor del registro puntero de pila, le
PUSH mem resta 4 y almacena el operando dado en los cuatro bytes de
PUSH $inm
memoria a partir de la posición del puntero de pila.
3. Instrucción de descarga sobre la pila

POP %reg El procesador toma el valor del registro puntero de pila y
POP mem
mueve ese dato al lugar indicado por el operando. Tras esta
transferencia, se suma el valor 4 al registro puntero de pila.

4. Instrucciones aritméticas
4.1. Instrucción de suma
ADD %regA, %regB
ADD $inm, %reg La instrucción de suma recibe dos operandos, los suma, y
ADD mem, %reg
ADD %reg, mem
deposita el resultado en el lugar especificado por el segundo
ADD $inm, mem operando perdiendo el valor del segundo operando.
4.2. Instrucción de resta
SUB %regA, %regB
SUB $inm, %reg La instrucción de resta recibe dos operandos, resta op1 a op2,
SUB mem, %reg
SUB %reg, mem
y deposita el resultado en el lugar especificado por el segundo
SUB $inm, mem operando perdiendo el valor del segundo operando.
4.3. Instrucción de cambio de signo
NEG %reg Esta instrucción es equivalente a multiplicar el valor del
NEG mem
operando por -1. El resultado se devuelve en el mismo
operando.
4.4. Instrucción de multiplicación con signo
IMUL %regA, %regB La instrucción multiplica ambos operandos. Esta instrucción
hace uso de los registros %eax y %edx para devolver el
resultado.
4.5. Instrucción de división con signo
IDIV %reg Esta instrucción realiza la división. El dividendo es implícito
IDIV mem
y se encuentra en el registro %eax y %edx; y el divisor es el
otro operando. El resultado se recoge en %eax.

5. Instrucciones lógicas
5.1. Instrucción de conjunción
AND %regA, %regB La conjunción bit a bit significa que ambos operandos deben
AND $inm, %reg tener el mismo tamaño y que cada bit del resultado se calcula
AND mem, %reg
AND %reg, mem
haciendo la conjunción de los correspondientes bits de ambos
AND $inm, mem operandos.
5.2. Instrucción de disyunción
OR %regA, %regB La disyunción exclusiva bit a bit significa que ambos
OR $inm, %reg operandos deben tener el mismo tamaño y que cada bit del
OR mem, %reg
OR %reg, mem
resultado se calcula haciendo la disyunción de los
OR $inm, mem correspondientes bits de ambos operandos
6. Instrucción de salto
6.1. Instrucción de salto incondicional
JMP %reg Esta instrucción simplemente cambia la secuencia de
JMP mem ejecución del procesador que ejecuta la instrucción indicada
en la posición de memoria dada como operando.
6.2. Instrucción de salto condicional
JE mem Esta instrucción ejecuta un salto si el valor de la posición de
memoria mem es igual a 0.
7. Instrucción de llamada a subrutina

CALL %reg El efecto relevante de esta instrucción es que deposita en la
CALL mem
cima de la pila la dirección de retorno, o lo que es lo mismo,
la dirección de la instrucción que sigue a esta en el flujo de
ejecución.

8. Instrucción de retorno de subrutina

RET Retorna la ejecución a la instrucción cuya dirección está
almacenada en la cima de la pila. Esta dirección se saca de la
pila.
9. Instrucción de comparación
OR %regA, %regB Esta instrucción realiza el cálculo op2 - op1.Su efecto se
OR $inm, %reg refleja únicamente en los flags de la palabra de estado. Estos
OR mem, %reg
OR %reg, mem
flags se pueden utilizar para, por ejemplo, cambiar el flujo de
OR $inm, mem ejecución mediante una instrucción de salto condicional.

Autómatas

Cargado por

Copyright:

Formatos disponibles

Autómatas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Autómatas

Cargado por

Copyright:

Formatos disponibles

Títol: Construcción de un compilador con parsing LL(*) y

Director/Ponent: José Miguel Rivero Almeida

Títol del Projecte: Construcción de un compilador con parsing LL(*) y StringTemplates

Nom de l'estudiant: Alicia González López

MEMBRES DEL TRIBUNAL (nom i signatura)

President: Ramón Ferrer Cancho

Vocal: Pilar Sobrevilla Frisón

Secretari: José Miguel Rivero Almeida

En primer lugar quiero agradecer a José Miguel Rivero la oportunidad de desarrollar un

Construcción de un compilador con parsing LL(*) y StringTemplates -7-

4.2. ANTLR Tree Parsing ...................................................................................... - 97 -

Construcción de un compilador con parsing LL(*) y StringTemplates -8-

Figura 1.1 - Etapas de un compilador ......................................................................... - 15 -

Construcción de un compilador con parsing LL(*) y StringTemplates - 10 -

Figura 3.6 - Árbol de activación del programa de la Figura 3.3 ................................ - 58 -

Construcción de un compilador con parsing LL(*) y StringTemplates - 11 -

Construcción de un compilador con parsing LL(*) y StringTemplates - 12 -

Figura 6.8 - Ejemplo II de programa en CL para la generación de Z-Code ............. - 128 -

Construcción de un compilador con parsing LL(*) y StringTemplates - 13 -

Figura I.3 - Código del mergesort (III) ..................................................................... - 173 -

Construcción de un compilador con parsing LL(*) y StringTemplates - 14 -

A modo de introducción, diremos que un compilador es un programa formado por las

Figura 1.1 - Etapas de un compilador

El objeto de estudio de este proyecto ha sido la implementación de un compilador

1.1. Objetivos del proyecto

Para conseguir el propósito final, se han marcado otros objetivos a alcanzar. A

Construcción de un compilador con parsing LL(*) y StringTemplates - 15 -

 Etapa de análisis o Front-end

o Ampliación del lenguaje CL, permitiendo el uso de memoria dinámica y

 Etapa de síntesis del código intermedio o Middle-end

o Definición del código intermedio Z-Code, una nueva representación

- Aportar legibilidad y facilidad de interpretación.

- Mayor eficiencia espacial y temporal del código generado.

- Facilitar el trabajo de optimización.

o Generación del código intermedio Z-Code.

 Etapa de síntesis del código objeto o Back-end

o Generación de código ensamblador IA-32.

1.2. Trabajos Previos

Construcción de un compilador con parsing LL(*) y StringTemplates - 16 -

1.3. Qué es un Compilador

Construcción de un compilador con parsing LL(*) y StringTemplates - 17 -

1.3.2. Etapas del Compilador

Figura 1.2 - Etapas con sus respectivas fases de un compilador

Construcción de un compilador con parsing LL(*) y StringTemplates - 18 -

En realidad, comprender el trabajo que realiza un compilador en sus primeras etapas es

A lo largo de la explicación, se hará referencia a estos dos ejemplos, mostrando cuál es

Figura 1.3 - Ejemplo de lenguaje natural Figura 1.4 - Ejemplo de programación

Dentro de la etapa de Análisis encontramos, según el orden en el que se realizan, las

 Análisis Léxico o Scanning. Durante esta fase se lee el código fuente y se

A medida que se fragmenta la entrada, también se comprueba la corrección de

Construcción de un compilador con parsing LL(*) y StringTemplates - 19 -

Después de esta fase, el resultado para ambos ejemplos sería el siguiente:

o Para el caso del lenguaje natural, se obtendría el siguiente listado de

o Para el caso de nuestro lenguaje de alto nivel CL deberíamos obtener el

Un posible error en este punto, se podría deber a que hay un conjunto de

 Análisis Sintáctico o Parsing. En este punto comprobamos si la secuencia de

oracion: sujeto predicado PUNTO

Figura 1.5 - Gramática de lenguaje natural