PROGRAMAS DE SISTEMAS RELACIONADOS CON UN COMPILADOR La entrada para un compilador puede producirse por uno o varios preprocesadores y puede necesitarse otro procesamiento de la salida que produce el compilador antes de obtener un código de máquina ejecutable.
Preprocesadores Los preprocesadores producen la entrada para un compilador, y pueden realizar las funciones siguientes: 1.
Procesamiento de macros. Un preprocesador puede permitir a un usuario definir macros, que son abreviaturas de construcciones más grandes.
2.
Inclusión de archivos. Un preprocesador puede insertar archivos de encabezamiento en el texto del programa. Por ejemplo, el preprocesador de C++ hace que el contenido del archivo remplace a la proposición #include cuando procesa un archivo que contenga a esa proposición.
3.
Preprocesadores Preprocesadores “racionales”. Estos preprocesadores enriquecen los lenguajes lenguajes antiguos con recursos más modernos de flujo de control y de estructuras de datos. Por ejemplo, un preprocesador de este tipo podría proporcionar al usuario macros incorporadas para construcciones, como proposiciones while o if, en un lenguaje de programación que no las tenga.
Los procesadores de macros tratan dos clases de proposiciones: definición de macros y uso de macros. Las definiciones normalmente se indican con algún carácter exclusivo o palabra clave, como define o define o macro. macro. Constan de un nombre para la macro que se está definiendo y de un cuerpo, que constituye su definición. A menudo, los procesadores de macros admiten parámetros formales en su definición, esto es, símbolos que se remplazarán por valores (en este contexto, un “valor” es una cadena de caracteres). El uso de una macro consiste en dar nombre a la macro y proporcionar parámetros reales, es decir, valores para sus parámetros formales. El procesador de macros sustituye los parámetros reales por los parámetros formales del cuerpo de la macro; después, el cuerpo transformado remplaza el uso de la propia macro.
Ensambladores Algunos compiladores producen código ensamblador. Otros compiladores realizan el trabajo de ensamblador, produciendo código de máquina relocalizable que se puede pasar directamente al editor de carga y enlace. Se supone que el lector tiene cierta familiaridad sobre cómo es un lenguaje ensamblador y que hace el ensamblador, aquí se revisará la relación entre el código ensamblador y el código de máquina. El código ensamblador es una versión mnemotécnica del código de máquina, donde se usan nombres en lugar de códigos binarios para operaciones y también se usan nombres para las direcciones de memoria. Una secuencia típica de instrucciones en ensamblador puede ser
MOV a,R1 ADD #2,R1 MOV R1, b Este código pasa el contenido de la dirección a al registro 1; después le suma la constante 2, tratando al contenido del registro 1 como un número de punto fijo, y por último almacena el resultado en la posición de memoria que represe nta b. De ese modo calculo b = a+2. Es común que los lenguajes ensambladores tengan recursos para manejar macros que son similares a las consideradas antes para los preprocesadores de macros.
Ensamblado de dos pasadas La forma más simple de un ensamblador hace dos pasadas sobre la entrada, en donde una pasada consiste en leer una vez un archivo de entrada. En la primera pasada se encuentran todos los identificadores que denoten posiciones de memoria y se almacenan en una tabla de símbolos (distinta de la del compilador). Cuando se encuentran por primera vez los identificadores, se les asignan posiciones de memoria, de modo que después de leer (ver figura 1 ) por ejemplo, la tabla de símbolos contendría las entradas que aparecen en la figura 2. En esa figura, se supone que se reserva una palabra, que consta de cuatro bytes, para cada identificador, y que las direcciones se asignan empezando a partir del byte 0.
FIGURA 1
FIGURA 2
En la segunda pasada, el ensamblador examina el archivo de entrada de nuevo. Esta vez traduce cada código de operación a la secuencia de bits que representa esa operación en lenguaje de máquina y traduce cada identificador que representa una posición de memoria a la dirección dad por ese identificador en la tabla de símbolos. El resultado de la segunda pasada normalmente es código de máquina relocalizable, lo que significa que puede cargarse empezando en cualquier posición L de la memoria; es decir, si se suma L a todas las direcciones del código, entonces todas las referencias serán correctas. Por tanto, la salida del ensamblador debe distinguir aquellas partes de instrucciones que se refieren a direcciones que se pueden relocalizar. El siguiente es un código de máquina hipotético al que se pueden traducir las instrucciones en ensamblador de la figura 1.
FIGURA 3 Se concibe una pequeña palabra de instrucción, en la que los cuatro primeros bits son el código de la instrucción, donde 0001, 0010, y 0011 representan las instrucciones LOAD, STORE y ADD, respectivamente. LOAD y STORE significan trasladar de memoria a un registro y viceversa. Los dos bits siguientes designan un registro y 01 se refiere al registro 1 de cada una de las tres instrucciones anteriores. Los dos bits siguientes representan un marcador, donde 00 es el modo de direccionamiento ordinario, y los últimos ocho bits se refieren a una dirección de memoria. El marcador 10 es el modo “inmediato”, donde los últimos ocho bits se toman literalmente com o el operando. Este modo aparece en la segunda instrucción de la figura anterior. En la figura también se ve un * asociado con la primera y la tercera instrucción. Este * representa el bit de relocalización que se asocia con cada operando en código de máquina relocalizable. Supóngase que el espacio de direcciones que contiene los datos se va a cargar empezando en la posición L. La presencia del * significa que se debe sumar L a la dirección de la instrucción. Por tanto, si L=000011111, esto es, 15, entonces a y b estarían en las posiciones 15 y 19 respectivamente y las instrucciones de la figura aparecer ían como
FIGURA 4 en código de máquina absoluto o no relocalizable. Nótese que no hay ningún * asociado con la segunda instrucción (Figura 3), de modo que L no se sumo a su dirección en (4), lo cual es correcto, porque los bits representan la constante 2 y no la posición 2.
Cargadores y editores de enlace Por lo general, un programa llamado cargador realiza las dos funciones de carga y edición de enlaces. El proceso de carga consiste en tomar el código de máquina relocalizable, modificar las direcciones relocalizables, como se indica en el ejemplo anteriormente visto, y ubicar las instrucciones y los datos modificados en las posiciones apropiadas de la memoria. El editor de enlace permite formar un solo programa a partir de varios archivos de código de máquina relocalizable. Estos archivos pueden haber sido el resultado de varias compilaciones
distintas, y uno o varios de ellos pueden ser archivos de biblioteca de rutinas proporcionadas por el sistema y disponibles para cualquier programa que las necesite. Si los archivos se van a usar juntos de manera útil., puede haber algunas referencias externas, en las que el código de un archivo hace referencia a una posición de otro archivo. Esta referencia puede ser a una posición de datos definida en un archivo y utilizada en otro, o puede ser el punto de entrada de un procedimiento que aparece en el código de un archivo y se llama desde otro. El archivo con el código de máquina relocalizable debe conservar la información de la tabla de símbolos para cada posición de datos o etiqueta de instrucción a la que se hace referencia externamente. Si no se sabe por anticipado a qué se va a hacer referencia, es preciso incluir completa la tabla de símbolos del ensamblador como parte del código de máquina relocalizable. Por ejemplo el código de la figura 3 iría precedido de a0 b4 Si un archivo cargado con (figura 3) hiciera referencia a b, entonces esa referencia se remplazaría por 4 más el desplazamiento con el que se localizarán las posiciones del archivo inicial.
EL AGRUPAMIENTO DE LAS FASES El estudio de las fases (anteriormente visto en el curso de Teoría de Lenguajes y compiladores) trata la organización lógica de un compilador. En una implantación, a menudo se agrupan las actividades en dos o más fases.
Etapa inicial y etapa final Con frecuencia, las fases se agrupan en una etapa inicial y una etapa final. La etapa inicial comprende aquellas fases, o partes e fases, que dependen principalmente del lenguaje fuente y que son en gran parte independientes de la máquina objeto. Ahí normalmente se incluyen los análisis léxico y sintáctico, la creación de la tabla de símbolos, el análisis semántico y la generación de código intermedio. La etapa inicial también puede hacer cierta optimación de código, La etapa inicial incluye, además, el manejo de errores c orrespondiente a cada una de esas fases. La etapa final incluye aquellas partes del compilador que dependen de la máquina objeto y en general esas partes no dependen del lenguaje fuente, sino sólo del lenguaje intermedio. En la etapa final, se encuentran aspectos de la fase de optimación de código, además de la generación de código, junto con el manejo de errores necesario y las operaciones con la tabla de símbolos. Se ha convertido en rutina el tomar la etapa inicial de un compilador y rehacer su etapa final asociada para producir un compilador para el mismo lenguaje fuente en una máquina distinta. Si la etapa final se diseña con cuidado, incluso puede no ser necesario rediseñarla demasiado. También resulta tentador compilar varios lenguajes distintos en el mismo lenguaje intermedio y usar una etapa final común para las distintas etapas iniciales, obteniéndose así varios compiladores para
una máquina. Sin embargo, dadas las sutiles diferencias en los puntos de vista de los distintos lenguajes, sólo se ha obtenido un éxito limitado en ese aspecto.
Pasadas Normalmente se aplican varias fases de la compilación en una sola pasada, que consiste en la lectura de un archivo de entrada y en la escritura de un archivo de salida. En la práctica hay muchas formas de agrupar en pasadas las fases de un compilador, así que es preferible organizar el análisis de la compilación por las fases, e n lugar de por las pasadas. Como ya se señaló, es común agrupar varias fases en una pasada, y entrelazar la actividad de estas fases durante la pasada. Por ejemplo, en análisis léxico, el análisis sintáctico, el análisis semántico y la generación de código intermedio pueden agruparse en una pasada. En ese caso, la cadena de componentes léxicos después del análisis léxico puede traducirse directamente a código intermedio. Con más detalle, el analizador sintáctico puede considerarse como el “encargado” del control. Este intenta descubrir la estructura gramatical de los componentes léxicos observador; obtiene los componentes léxicos cuando los necesita, llamando al analizador léxico para que le proporcione el siguiente componente léxico. A medida que se descubre la estructura gramatical, el analizador sintáctico llama al generador de código intermedio para que se haga el análisis semántico y genere una parte del código.
Reducción del número de pasadas Es deseable tener relativamente pocas pasadas, dado que la lectura y escritura de archivos intermedios lleva tiempo. Además, si se agrupan varias fases dentro de una pasada, puede ser necesario tener que mantener el programa completo en memoria, porque una fase puede necesitar información en un orden distinto al que produce una fase previa. La forma interna del programa puede ser considerablemente mayor que el programa fuente o el programa objeto, de modo que este espacio no es un tema trivial. Para algunas fases, el agrupamiento en una pasada presenta pocos problemas. Por ejemplo. Como se mencionó antes, la interfaz entre los analizadores léxico y sintáctico a menudo puede limitarse a un solo componente léxico. Por otra parte, muchas veces resulta muy difícil ge nerar código hasta que se haya generado por completo la representación intermedia. Por ejemplo, lenguajes como ALGOL 68 permiten usar las variables antes de declararlas. No se puede generar el código objeto para una construcción si no se conocen los tipos de las variables implicadas en esa construcción. De manera similar, la mayoría de los lenguajes admiten construcciones goto que saltan hacia adelante en el código. No se puede determinar la dirección objeto de dichos saltos hasta haber visto el código fuente implicado y haber generado código objeto para él. En algunos casos, es posible dejar un segmento en blanco para la información que falta, y llenar la ranura cuando la información esté disponible. En particular, la generación de código intermedio y de código objeto a menudo se pueden fusionar en una sola pasada utilizando una técnica llamada “relleno de retroceso” (backpatching). Aunque no se pueden explicar todos los detalles se puede
ilustrar el relleno de retroceso partiendo de un ensamblador. Recordemos que anteriormente se analizó un ensamblador de dos pasadas, en el que la primera pasada descubría todos los identificadores que representaban posiciones de memoria y deducía sus direcciones al descubrirlas. Después, en una segunda pasada sustituía las direcciones por identificadores. Se puede combinar la acción de las pasadas como sigue. Al encontrar una proposición en ensamblador que sea una referencia hacia adelante, por ejemplo. GOTO destino Se genera la estructura de una instrucción, con el código de operación de máquina para GOTO y se dejan espacios en blanco para la dirección. Todas las instrucciones, con espacios en blanco para la dirección de destino se guardan en una lista asociada con la entrada de destino de la tabla de símbolos. Los espacios se llenan por fin se encuentra una instrucción c omo. Destino: MOV algo, R1 Y se determina el valor de destino, es la dirección de la instrucción en curso. Entonces se hace el relleno de retroceso, recorriendo la lista de destino de todas las instrucciones que necesitan su dirección, sustituyendo la dirección de destino en los espacios en blanco que aparecen en los campos de dirección de esas instrucciones. Este enfoque es fácil de implementar si las instrucciones se pueden guardar en memoria hasta que se hayan determinado todas las direcciones de destino. Este enfoque es razonable para un ensamblador que pueda guardar toda una salida en memoria. Como las representaciones intermedia y final del código para un ensamblador son aproximadamente iguales, y con seguridad casi de la misma longitud, el relleno de retroceso en toda la longitud del programa ensamblador no es inviable. Sin embargo, en un compilador, con un código intermedio que consuma mucho espacio, habrá que tener cuidado con la distancia en que se hace el relleno de retroceso.
HERRAMIENTAS PARA LA CONSTRUCCIÓN DE COMPILADORES El escritor del compilador, como cualquier programador, puede usar con provecho herramientas de software tales como depuradores, administradores de versiones, analizadores, etcétera. Además de estas herramientas de desarrollo de software, se han creado herramientas para especializadas para ayudar a implantar varias fases de un compilador. En esta sección se mencionan brevemente. Poco después de escribirse el primer compilador, aparecieron sistemas para ayudar en el proceso de escritura de compiladores. A menudo se hace referencia a estos sistemas como compiladores de compiladores, generadores de compiladores o sistemas generadores de traductores. En gran parte, se orientan en torno a un modelo particular de lenguaje, y son más adecuados para generar compiladores de lenguajes similares al del modelo.
Por ejemplo, es tentador suponer que los analizadores léxicos para todos los lenguajes son en esencia iguales, excepto por las palabras clave y signos particulares que se reconocen. Muchos compiladores de compiladores de hecho producen rutinas fijas de análisis léxico para usar en el compilador generado. Estas rutinas sólo difieren en la lista de palabras clave que reconocen, y esta lista es todo lo que debe proporcionar el usuario. El planteamiento es válido, pero puede no ser funcional si se requiere que reconozca componentes léxicos no estándar, como identificadores que pueden incluir ciertos caracteres distintos de letras y dígitos. Se han creado algunas herramientas generales para el diseño automático de componentes específicos de compilador. Estas herramientas utilizan lenguajes especializados para especificar e implantar el componente y pueden utilizar algoritmos bastante complejos. Las herramientas más efectivas son las que ocultan los detalles del algoritmo de generación y producen componentes que se pueden integrar con facilidad al resto del compilador. La siguiente es una lista de algunas herramientas útiles para la construcción de compiladores: 1.
Generadores de analizadores sintácticos. Estos generadores producen analizadores sintácticos, normalmente a partir de una entrada fundamentada en una gramática independiente del contexto. En los primeros compiladores, el análisis sintáctico consumía no solo gran parte del tiempo de ejecución del compilador, sino gran parte del esfuerzo intelectual de escribirlo. Esta fase se considera ahora una de las más fáciles de aplicar Muchos de los generadores de analizadores sintácticos utilizan poderosos algoritmos de análisis sintáctico y son demasiado com plejos para realizarlos manualmente.
2.
Generadores de analizadores léxicos. Estas herramientas generan automáticamente analizadores léxicos, por lo general a partir de una especificación basada en expresiones regulares. La organización básica del analizador léxico resultante es en realidad un autómata finito.
3.
Dispositivos de traducción dirigida por la sintaxis. Estos producen grupos de rutinas que recorren el árbol de análisis sintáctico. La idea básica es que se asocian una o más “traducciones” con cada nodo del árbol de análisis sintáctico, y cada traducción se define partiendo de traducciones en sus nodos vecinos en el árbol.
4.
Generadores automáticos de código. Tales herramientas toman un conjunto de reglas que definen la traducción de cada operación del lenguaje intermedio al lenguaje de máquina para la máquina objeto. Las reglas deben incluir suficiente detalle para poder manejar los distintos métodos de acceso posibles a los datos; por ejemplo, las variables pueden estar en registros, en un posición fija (estática) de memoria o pueden tener asignada una posición en una pila. La técnica fundamental es la de “concordancia de plantillas”. Las proposiciones de código intermedio se remplazan por “plantillas” que representan secuencias de instrucciones de máquina, de modo que las suposiciones sobre el almacenamiento de las variables concuerden de plantilla a plantilla. Como suele haber muchas opciones en relación con la ubicación de las variables (por ejemplo, en uno o varios registros o en memoria), hay muchas formas posibles de “cubrir” el código
intermedio con un conjunto dado de plantillas, y es necesario seleccionar una buena cobertura sin una explosión combinatoria en el tiempo de e jecución del compilador. 5.
Dispositivos para análisis de flujo de datos. Mucha de la información necesaria para hacer una buena optimación de código implica hacer un “análisis de flujo de datos” que consiste en la recolección de información sobre la forma en que se transmiten los valores de una parte de un programa a cada una de las otras partes. Las distintas tareas de esta naturaleza se pueden efectuar esencialmente con la misma rutina. En la que el usuario proporciona los detalles relativos a la relación que hay entre las proposiciones en código intermedio y la información que se está recolectando.
