Herramientas
Utilidades y Generadores de Compiladores
A continuación se muestran algunas de las herramientas disponibles que pueden utilizarse para la realización del Proyecto de Compiladores. Todas estas herramientas funcionan bajo Windows.
Herramientas para la construcción de compiladores Herramienta Lenguaje Descripción
Bison C Generador de Analizadores Sintácticos Ascendentes tipo YACC
COCO/R C/C++ Generador de Analizadores Léxicos y Sintácticos Descendentes Recursivos
Flex C Generador de Analizadores Léxicos tipo Lex
Lex C Generador de Analizadores Léxicos
SDGLL1 exe Sistema Detector de Gramáticas LL(1)
TS 2006 C/C++ Tipo abstracto de datos Tabla de Símbolos de uso sencillo (beta 0.4)
TS C Tipo abstracto de datos Tabla de Símbolos
TS-OO C++ Tipo abstracto de datos Tabla de Símbolos
YACC C Generador de Analizadores Sintácticos Ascendentes LR(1)
Nota: El uso de estas herramientas de compiladores no es en absoluto obligatorio ni se garantiza su correcto funcionamiento. Se muestran aquí solamente a título informativo. Los profesores de la asignatura no proporcionarán ayuda ni información adicional sobre dichas herramientas.
Ensambladores Simbólicos ENS
Los ensambladores simbólicos ENS permiten ensamblar, ejecutar y depurar el código ensamblador generado por el compilador. Dentro de los ficheros comprimidos que se pueden obtener en la tabla, se encuentra información sobre su uso, su sintaxis y algún ejemplo de funcionamiento. El compilador construido en el Proyecto de Compiladores tiene que generar como código objeto uno de estos ensambladores.
Ensambladores simbólicos Versión ENS S.O. Descripción
ENS 2001 DOS (Consola Windows) Lenguaje ensamblador basado en el estándar IEEE 694. Entorno textual de ensamblado y depuración.
W-ENS 2001 Windows Lenguaje ensamblador basado en el estándar IEEE 694. Entorno gráfico de ensamblado y depuración.
L-ENS 2001 Linux Lenguaje ensamblador basado en el estándar IEEE 694. Entorno textual de ensamblado y depuración. Incluye fuentes.
ASS 1.3 Linux Lenguaje ensamblador sencillo. Entorno textual de ensamblado y depuración. Incluye fuentes.
ENS 96 DOS Lenguaje ensamblador basado en un estándar IEEE 694 reducido. Entorno textual de ensamblado y depuración.
miércoles, 13 de mayo de 2009
Generador de código intermedio
El analizador sintactico va generando acciones que valida el analizador semántico y que se convierten en tercetos. Esta conversión en tercetos constituye el generador de código intermedio.
Dado que el lenguaje puede presentar distintas funciones anidadas, los tercetos los generamos por orden del parser y son almacenados en un sitio u otro dependiendo del contexto en que nos encontremos. Es decir, se almacenan en una lista de tercetos dependiente de la Tabla de Simbolos. Hay tantas listas de tercetos como funciones haya en el código fuente más una lista de tercetos asociada a la Tabla de Simbolos Global
No obstante una vez finalizado el análisis, todos estos tercetos repartidos en distintas listas se vuelcan a una sola lista de tercetos global. Esta será la que finalmente se optimice y a partir de la que se generará el programa en ensamblador.
El problema de tener que manejar tercetos indirectos fue resuelto modificando el método de inserción sobre la lista de tercetos utilizada en cada momento, de manera que se realiza previamente una búsqueda de algún terceto que sea exactamente igual al que estamos insertando. En caso afirmativo, insertamos en la lista no un terceto nuevo, sino un puntero al ya existente, y marcamos dicho terceto como terceto indirecto. Son tercetos indirectos aquellos marcados con un asterisco despúes del índice en los volcados de la lista de tercetos.
Dado que el lenguaje puede presentar distintas funciones anidadas, los tercetos los generamos por orden del parser y son almacenados en un sitio u otro dependiendo del contexto en que nos encontremos. Es decir, se almacenan en una lista de tercetos dependiente de la Tabla de Simbolos. Hay tantas listas de tercetos como funciones haya en el código fuente más una lista de tercetos asociada a la Tabla de Simbolos Global
No obstante una vez finalizado el análisis, todos estos tercetos repartidos en distintas listas se vuelcan a una sola lista de tercetos global. Esta será la que finalmente se optimice y a partir de la que se generará el programa en ensamblador.
El problema de tener que manejar tercetos indirectos fue resuelto modificando el método de inserción sobre la lista de tercetos utilizada en cada momento, de manera que se realiza previamente una búsqueda de algún terceto que sea exactamente igual al que estamos insertando. En caso afirmativo, insertamos en la lista no un terceto nuevo, sino un puntero al ya existente, y marcamos dicho terceto como terceto indirecto. Son tercetos indirectos aquellos marcados con un asterisco despúes del índice en los volcados de la lista de tercetos.
Gestion de memoria en tiempo de ejecucion
Cuando un programa se ejecuta sobre un sistema operativo existe un proceso previo
llamado cargador que suministra al programa un bloque contiguo de memoria sobre el
cual ha de ejecutarse. El programa resultante de la compilación debe organizarse de
forma que haga uso de este bloque. Para ello el compilador incorpora al programa objeto
el código necesario.
Las técnicas de gestión de la memoria durante la ejecución del programa difieren de unos lenguajes a otros, e incluso de unos compiladores a otros.
Para lenguajes imperativos, los compiladores generan programas que tendrán en tiempo
de ejecución una organización de la memoria similar (a grandes rasgos) a la que aparece
en la figura 1.
En este esquema se distinguen las secciones de:
- El Código
- La Memoria Estática.
- La Pila.
- El Montón.
El código:
Es la zona donde se almacenan las instrucciones del programa ejecutable en código
máquina, y también el código correspondiente a los procedimientos y funciones que
utiliza. Su tamaño puede fijarse en tiempo de compilación.
La memoria estática
La forma más fácil de almacenar el contenido de una variable en memoria en tiempo de
ejecución es en memoria estática o permanente a lo largo de toda la ejecución del
programa. No todos los objetos (variables) pueden ser almacenados estáticamente. Para
que un objeto pueda ser almacenado en memoria estática su tamaño ( número de bytes
necesarios para su almacenamiento) ha de ser conocido en tiempo de compilación. Como
consecuencia de esta condición no podrán almacenarse en memoria estática:
• Los objetos correspondientes a procedimientos o funciones recursivas, ya que en tiempo
de compilación no se sabe el número de variables que serán necesarias.
• Las estructuras dinámicas de datos tales como listas, árboles, etc. ya que el número de
elementos que la forman no es conocido hasta que el programa se ejecuta.
La Pila
La aparición de lenguajes con estructura de bloque trajo consigo la necesidad de técnicas
de alojamiento en memoria más flexibles, que pudieran adaptarse a las demandas de
memoria durante la ejecución del programa. En estos lenguajes, cada vez que comienza
la ejecución de un procedimiento se crea un registro de activación para contener los
objetos necesarios para su ejecución, eliminandolo una vez terminada ésta.
Dado que los bloques o procedimientos están organizados jerárquicamente, los distintos
registros de activación asociados a cada bloque deberán colocarse en una pila en la que
entrarán cuando comience la ejecución del bloque y saldrán al terminar el mismo. (Fig.
5b) La estructura de los registros de activación varía de unos lenguajes a otros, e incluso
de unos compiladores a otros. Este es uno de los problemas por los que a veces resulta
difícil enlazar los códigos generados por dos compiladores diferentes. En general, los
registros de activación de los procedimientos suelen tener algunos de los campos que
pueden verse en la fig.
5a.
llamado cargador que suministra al programa un bloque contiguo de memoria sobre el
cual ha de ejecutarse. El programa resultante de la compilación debe organizarse de
forma que haga uso de este bloque. Para ello el compilador incorpora al programa objeto
el código necesario.
Las técnicas de gestión de la memoria durante la ejecución del programa difieren de unos lenguajes a otros, e incluso de unos compiladores a otros.
Para lenguajes imperativos, los compiladores generan programas que tendrán en tiempo
de ejecución una organización de la memoria similar (a grandes rasgos) a la que aparece
en la figura 1.
En este esquema se distinguen las secciones de:
- El Código
- La Memoria Estática.
- La Pila.
- El Montón.
El código:
Es la zona donde se almacenan las instrucciones del programa ejecutable en código
máquina, y también el código correspondiente a los procedimientos y funciones que
utiliza. Su tamaño puede fijarse en tiempo de compilación.
La memoria estática
La forma más fácil de almacenar el contenido de una variable en memoria en tiempo de
ejecución es en memoria estática o permanente a lo largo de toda la ejecución del
programa. No todos los objetos (variables) pueden ser almacenados estáticamente. Para
que un objeto pueda ser almacenado en memoria estática su tamaño ( número de bytes
necesarios para su almacenamiento) ha de ser conocido en tiempo de compilación. Como
consecuencia de esta condición no podrán almacenarse en memoria estática:
• Los objetos correspondientes a procedimientos o funciones recursivas, ya que en tiempo
de compilación no se sabe el número de variables que serán necesarias.
• Las estructuras dinámicas de datos tales como listas, árboles, etc. ya que el número de
elementos que la forman no es conocido hasta que el programa se ejecuta.
La Pila
La aparición de lenguajes con estructura de bloque trajo consigo la necesidad de técnicas
de alojamiento en memoria más flexibles, que pudieran adaptarse a las demandas de
memoria durante la ejecución del programa. En estos lenguajes, cada vez que comienza
la ejecución de un procedimiento se crea un registro de activación para contener los
objetos necesarios para su ejecución, eliminandolo una vez terminada ésta.
Dado que los bloques o procedimientos están organizados jerárquicamente, los distintos
registros de activación asociados a cada bloque deberán colocarse en una pila en la que
entrarán cuando comience la ejecución del bloque y saldrán al terminar el mismo. (Fig.
5b) La estructura de los registros de activación varía de unos lenguajes a otros, e incluso
de unos compiladores a otros. Este es uno de los problemas por los que a veces resulta
difícil enlazar los códigos generados por dos compiladores diferentes. En general, los
registros de activación de los procedimientos suelen tener algunos de los campos que
pueden verse en la fig.
5a.
Suscribirse a:
Entradas (Atom)
.jpg)
