Edlizabeth Ponce 29.803.

764

La comunicació n entre un ordenador y una persona, y có mo esta comunicació n se realiza principalmente mediante
el envío y recepció n de mensajes de tipo textual. El usuario escribe una orden mediante el teclado, y el ordenador
la ejecuta devolviendo como resultado un mensaje informativo sobre las acciones llevadas a cabo. Aunque la
evolució n de los ordenadores se encuentra dirigida actualmente hacia el empleo de novedosas y ergonó micas
interfaces de usuario (como el rató n, las pantallas tá ctiles, las tabletas grá ficas, etc.), podemos decir que casi todas
las acciones que el usuario realiza sobre estas interfaces se traducen antes o después a secuencias de comandos
que son ejecutadas como si hubieran sido introducidas por teclado. Por otro lado, el trabajo que el profesional de la
Informá tica realiza sobre el ordenador se encuentra plagado de situaciones en las que se produce una
comunicació n textual directa con la má quina: utilizació n de un intérprete de comandos (shell), construcció n de
ficheros de trabajo por lotes, programació n mediante diversos lenguajes, etc. Incluso los procesadores de texto
como WordPerfect y MS Word almacenan los documentos escritos por el usuario mediante una codificació n textual
estructurada que, cada vez que se abre el documento, es reconocida, recorrida y presentada en pantalla.

La necesidad de conocer los entresijos de la herramienta que utiliza un informá tico durante su trabajo diario y
sobre la que descansa la interacció n hombre-má quina: el traductor. El texto también menciona que puede ser muy
ú til conocer có mo funcionan las distintas partes de un compilador, especialmente aquella que se encarga de trocear
los textos fuentes y convertirlos en frases sintá cticamente vá lidas. Ademá s, se presenta una situació n de aparente
complejidad en la que se posee un documento de MS Word que procede de una fusió n con una base de datos y se
quiere, a partir de él, obtener la B.D. original. La solució n propuesta es convertir el documento a formato texto
puro, procesar dicho texto con un traductor para eliminar los caracteres superfluos y dar como resultado otro texto
en el que cada campo de la tabla de la B.D. está entre comillas. Finalmente, el texto sugiere que el texto anterior se
importe con cualquier SGBD.

Otras aplicaciones de la construcció n de traductores pueden ser la creació n de preprocesadores para lenguajes que
no lo tienen (por ejemplo, para trabajar fá cilmente con SQL en C, se puede hacer un preprocesador para introducir
SQL inmerso), o incluso la conversió n del cará cter ASCII 10 (LF) en “” de HTML para pasar texto a la web.

un traductor como un programa que traduce o convierte desde un texto o programa escrito en un lenguaje fuente
hasta un texto o programa equivalente escrito en un lenguaje destino produciendo, si cabe, mensajes de error. Los
traductores engloban tanto a los compiladores (en los que el lenguaje destino suele ser có digo má quina) como a los
intérpretes (en los que el lenguaje destino está constituido por las acciones ató micas que puede ejecutar el
intérprete).

El texto que me has enviado habla sobre la evolució n de los traductores y có mo su desarrollo ha estado plagado de
problemas y errores hasta que la teoría de autó matas y lenguajes formales se aplicó a la creació n de traductores.
También se menciona que en la década de 1950, se consideró a los traductores como programas notablemente
difíciles de escribir. El primer compilador de Fortran (Formula Translator), por ejemplo, necesitó para su
implementació n el equivalente a 18 añ os de trabajo individual (realmente no se tardó tanto puesto que el trabajo
se desarrolló en equipo). Sin embargo, hoy día un compilador bá sico puede ser el proyecto fin de carrera de
cualquier estudiante universitario de Informá tica. Desde los orígenes de la computació n, ha existido un abismo
entre la forma en que las personas expresan sus necesidades y la forma en que un ordenador es capaz de
interpretar instrucciones. Los traductores han intentado salvar este abismo para facilitarles el trabajo a los
humanos, lo que ha llevado a aplicar la teoría de autó matas a diferentes campos y á reas concretas de la
informá tica, dando lugar a los distintos tipos de traductores.

Los traductores del idioma y los problemas que presentan. Estos traductores se encargan de traducir de un idioma
dado a otro, como por ejemplo del inglés al españ ol. Los problemas que presentan incluyen la necesidad de
inteligencia artificial y el problema de las frases hechas, la dificultad en la formalizació n en la especificació n del
significado de las palabras, y el cambio del sentido de las palabras segú n el contexto. En general, los resultados má s
satisfactorios en la traducció n del lenguaje natural se han producido sobre subconjuntos restringidos del lenguaje,
como discursos jurídicos y documentació n técnica.
Por otro lado, los compiladores, son aquellos traductores que tienen como entrada una sentencia en lenguaje
formal y como salida tienen un fichero ejecutable. Es decir, realizan una traducció n de un có digo de alto nivel a
có digo má quina. También se entiende por compilador aquel programa que proporciona un fichero objeto en lugar
del ejecutable final

los intérpretes, que son como un compilador, solo que la salida es una ejecució n. El programa de entrada se
reconoce y ejecuta a la vez. No se produce un resultado físico (có digo má quina) sino ló gico (una ejecució n). Hay
lenguajes que só lo pueden ser interpretados, como p.ej. SNOBOL (StriNg Oriented SimBOlyc Language), LISP (LISt
Processing), algunas versiones de BASIC (Beginner’s All-purpose Symbolic Instruction Code), etc. Su principal
ventaja es que permiten una fá cil depuració n. Entre los inconvenientes podemos citar, en primer lugar, la lentitud
de ejecució n, ya que al ejecutar a la vez que se traduce no puede aplicarse un alto grado de optimizació n; por
ejemplo, si el programa entra en un bucle y la optimizació n no está muy afinada, las mismas instrucciones se
interpretará n y ejecutará n una y otra vez, enlenteciendo la ejecució n del programa. Otro inconveniente es que
durante la ejecució n, el intérprete debe residir en memoria, por lo que consumen má s recursos

los preprocesadores y los intérpretes de comandos. Los preprocesadores permiten modificar el programa fuente
antes de la verdadera compilació n. Hacen uso de macroinstrucciones y directivas de compilació n. Por ejemplo, en
lenguaje C, el preprocesador sustituye la directiva #include Uno.c por el có digo completo que contiene el fichero
“Uno.c”, de manera que cuando el compilador comienza su ejecució n se encuentra con el có digo ya insertado en el
programa fuente. Algunas otras directivas de pre procesamiento permiten compilar trozos de có digos opcionales
(lenguajes C y Clipper): #fi, #ifdef, #define, #ifndef, etc. Los preprocesadores suelen actuar de manera transparente
para el programador, pudiendo incluso considerarse que son una fase preliminar del compilador.

Por otro lado, los intérpretes de comandos traducen sentencias simples a invocaciones a programas de una
biblioteca. Se utilizan especialmente en los sistemas operativos (la shell de Unix es un intérprete de comandos). Los
programas invocados pueden residir en el kernel (nú cleo) del sistema o estar almacenados en algú n dispositivo
externo como rutinas ejecutables que se traen a memoria bajo demanda. Por ejemplo, si bajo MS-DOS se teclea el
comando copy se ejecutará la funció n de copia de ficheros del sistema operativo, que se encuentra residente en
memoria

El texto que me has enviado habla sobre los ensambladores, que son los pioneros de los compiladores, ya que en
los albores de la informá tica, los programas se escribían directamente en có digo má quina, y el primer paso hacia
los lenguajes de alto nivel lo constituyen los ensambladores. En lenguaje ensamblador se establece una relació n
biunívoca entre cada instrucció n y una palabra mnemotécnica, de manera que el usuario escribe los programas
haciendo uso de los mnemotécnicos, y el ensamblador se encarga de traducirlo a có digo má quina puro. De esta
manera, los ensambladores suelen producir directamente có digo ejecutable en lugar de producir ficheros objeto.
Un ensamblador es un compilador sencillo, en el que el lenguaje fuente tiene una estructura tan sencilla que
permite la traducció n de cada sentencia fuente a una ú nica instrucció n en có digo má quina. Al lenguaje que admite
este compilador también se le llama lenguaje ensamblador. En definitiva, existe una correspondencia uno a uno
entre las instrucciones ensamblador y las instrucciones má quina.

Por otro lado, existen ensambladores avanzados que permiten definir macroinstrucciones que se pueden traducir a
varias instrucciones má quina. A estos programas se les llama macroensambladores, y suponen el siguiente paso
hacia los lenguajes de alto nivel. Desde un punto de vista formal, un macroensamblador puede entenderse como un
ensamblador con un preprocesador previo.

Ademá s, los conversores fuente-fuente, que permiten traducir desde un lenguaje de alto nivel a otro lenguaje de
alto nivel con lo que se consigue una mayor portabilidad en los programas de alto nivel. Por ejemplo, si un
ordenador só lo dispone de un compilador de Pascal, y queremos ejecutar un programa escrito para otra má quina
en COBOL, pues un conversor de COBOL a Pascal solucionará el problema.

No se genera directamente un fichero ejecutable para permitir la compilació n separada, de manera que varios
programadores puedan desarrollar simultá neamente las partes de un programa má s grande y, lo que es má s
importante, puedan compilarlos independientemente y realizar una depuració n en paralelo. Una vez que cada una
de estas partes ha generado su correspondiente fichero objeto, estos deben fusionarse para generar un solo
ejecutable.
Un fichero objeto posee una estructura de mó dulos también llamados registros. Estos registros tienen longitudes
diferentes dependiendo de su tipo y cometido. Ciertos tipos de estos registros almacenan có digo má quina, otros
poseen informació n sobre las variables globales, y otros incluyen informació n sobre los objetos externos (p. ej,
variables que se supone que está n declaradas en otro ficheros. El lenguaje C permite explícitamente esta situació n
mediante el modificador “extern”).

Durante la fase de enlace, el enlazador o linker resuelve las referencias cruzadas, (así se llama a la utilizació n de
objetos externos), que pueden estar declarados en otros ficheros objeto, o en librerías (ficheros con extensió n “lib”
o “dll”), engloba en un ú nico bloque los distintos registros que almacenan có digo má quina, estructura el bloque de
memoria destinado a almacenar las variables en tiempo de ejecució n y genera el ejecutable final incorporando
algunas rutinas adicionales procedentes de librerías, como por ejemplo las que implementan funciones
matemá ticas o de e/s bá sicas.

Cuando el enlazador construye el fichero ejecutable, asume que cada segmento va a ser colocado en la direcció n 0
de la memoria. Como el programa va a estar dividido en segmentos, las direcciones a las que hacen referencia las
instrucciones dentro de cada segmento (instrucciones de cambio de control de flujo, de acceso a datos, etc.), no se
tratan como absolutas, sino que son direcciones relativas a partir de la direcció n base en que sea colocado cada
segmento en el momento de la ejecució n.

El cargador carga el fichero .exe, coloca sus diferentes segmentos en memoria (donde el sistema operativo le diga
que hay memoria libre para ello) y asigna los registros base a sus posiciones correctas, de manera que las
direcciones relativas funcionen correctamente.

Cada vez que una instrucció n má quina hace referencia a una direcció n de memoria (partiendo de la direcció n 0), el
microprocesador se encarga automá ticamente de sumar a dicha direcció n la direcció n absoluta de inicio de su
segmento. Por ejemplo, para acceder a la variable x almacenada en la direcció n 1Fh, que se encuentra en el
segmento de datos ubicado en la direcció n 8A34h, la instrucció n má quina hará referencia a 1Fh, pero el
microprocesador la traducirá por 8A34h+1Fh dando lugar a un acceso a la direcció n 8A53h: dir absoluta del
segmento en memoria + dir relativa de x en el segmento = dir absoluta de x en memoria.

Las pasadas de compilació n, que es el nú mero de veces que un compilador debe leer el programa fuente para
generar el có digo. Hay algunas situaciones en las que, para realizar la compilació n, no es suficiente con leer el
fichero fuente una sola vez. Por ejemplo, en situaciones en las que existe recursió n indirecta (una funció n A llama a
otra B y la B llama a la A). Cuando se lee el cuerpo de A, no se sabe si B está declarada má s adelante o se le ha
olvidado al programador; o si lo está , si los pará metros reales coinciden en nú mero y tipo con los formales o no. Es
má s, aunque todo estuviera correcto, aú n no se ha generado el có digo para B, luego no es posible generar el có digo
má quina correspondiente a la invocació n de B puesto que no se sabe su direcció n de comienzo en el segmento de
có digo. Por todo esto, en una pasada posterior hay que controlar los errores y rellenar los datos que faltan.

Diferentes compiladores y lenguajes solucionan este problema de maneras distintas. Una solució n consiste en
hacer dos o má s pasadas de compilació n, pero ello consume demasiado tiempo puesto que las operaciones de e/s
son, hoy por hoy, uno de los puntos fundamentales en la falta de eficiencia de los programas (incluidos los
compiladores). Otra solució n pasa por hacer una sola pasada de compilació n y modificar el lenguaje obligando a
hacer las declaraciones de funciones recursivas indirectas antes de su definició n. De esta manera, lenguajes como
Pascal o Modula-2 utilizan la palabra reservada FORWARD para ello: FORWARD precede la declaració n de B, a
continuació n se define A y por ú ltimo se define B. Lenguajes como C también permiten el no tener que declarar una
funció n si ésta carece de pará metros y devuelve un entero.

La compilació n incremental es una técnica que se utiliza para recompilar só lo las modificaciones realizadas desde
la ú ltima compilació n. Lo ideal es que só lo se recompilen aquellas partes que contenían los errores o que, en
general, hayan sido modificadas, y que el có digo generado se reinserte con cuidado en el fichero objeto generado
en la ú ltima compilació n. La compilació n incremental se puede llevar a cabo con distintos grados de afinació n. Por
ejemplo, si se olvida un ‘;’ en una sentencia, se podría generar un fichero objeto transitorio parcial. Si se corrige el
error y se añ ade el ‘;’ que falta y se recompila, un compilador incremental puede funcionar a varios niveles: a nivel
de cará cter, a nivel de sentencia, a nivel de bloque, o a nivel de fichero fuente. Lo ideal es que se hiciese
eficientemente a nivel de sentencia, pero lo normal es encontrarlo a nivel de fichero. La mayoría de los
compiladores actuales realizan una compilació n incremental a este nivel.

Un autocompilador es un compilador escrito en el mismo lenguaje que compila (o parecido). Normalmente, cuando
se extiende entre muchas má quinas diferentes el uso de un compilador, y éste se desea mejorar, el nuevo
compilador se escribe utilizando el lenguaje del antiguo, de manera que pueda ser compilado por todas esas
má quinas diferentes, y dé como resultado un compilador má s potente de ese mismo lenguaje.

Por otro lado, un metacompilador es un compilador de compiladores. Se trata de un programa que acepta como
entrada la descripció n de un lenguaje y produce el compilador de dicho lenguaje. Hoy por hoy no existen
metacompiladores completos, pero sí parciales en los que se acepta como entrada una gramá tica de un lenguaje y
se genera un autó mata que reconoce cualquier sentencia del lenguaje. A este autó mata podemos añ adirle có digo
para completar el resto del compilador. Ejemplos de metacompiladores son: Lex, YACC, FLex, Bison, JavaCC, JLex,
Cup, PCCTS, MEDISE, etc.

Los metacompiladores se suelen dividir entre los que pueden trabajar con gramá ticas de contexto libre y los que
trabajan con gramá ticas regulares. Los primeros se dedican a reconocer la sintaxis del lenguaje y los segundos
trocean los ficheros fuente y lo dividen en palabras. PCLex es un metacompilador que genera la parte del
compilador destinada a reconocer las palabras reservadas. PCYACC es otro metacompilador que genera la parte del
compilador que informa sobre si una sentencia del lenguaje es vá lida o no. JavaCC es un metacompilador que aú na
el reconocimiento de palabras reservadas y la aceptació n o rechazo de sentencias de un lenguaje. PCLex y PCYACC
generan có digo C y admiten descripciones de un lenguaje mediante gramá ticas formales, mientras que JavaCC
produce có digo Java y admite descripciones de lenguajes expresadas en notació n BNF (Backus-Naur Form).

Un descompilador es un programa que realiza una labor de traducció n inversa, es decir, convierte el có digo
má quina (programa de salida) al equivalente escrito en el lenguaje que lo generó (programa fuente) ². Cada
descompilador trabaja con un lenguaje de alto nivel concreto. La descompilació n suele ser una labor casi imposible,
porque al có digo má quina generado casi siempre se le aplica una optimizació n en una fase posterior, de manera
que un mismo có digo má quina ha podido ser generado a partir de varios có digos fuente. Por esto, só lo existen
descompiladores de aquellos lenguajes en los que existe una relació n biyectiva entre el có digo destino y el có digo
fuente, como sucede con los desensambladores, en los que a cada instrucció n má quina le corresponde una y só lo
una instrucció n ensamblador.

Los descompiladores se utilizan especialmente cuando el có digo má quina ha sido generado con opciones de
depuració n, y contiene informació n adicional de ayuda al descubrimiento de errores (puntos de ruptura,
seguimiento de trazas, opciones de visualizació n de variables, etc.). También se emplean cuando el compilador no
genera có digo má quina puro, sino pseudocó digo para ser ejecutado a través de un pseudointérprete. En estos casos
suele existir una relació n biyectiva entre las instrucciones del pseudocó digo y las construcciones sintá cticas del
lenguaje fuente, lo que permite reconstruir un programa de alto nivel a partir del de un bloque de pseudocó digo.

Existen varios descompiladores disponibles en el mercado, como dotPeek , que es una herramienta gratuita basada
en ReSharper. Puede decompilar de forma segura cualquier ensamble .NET a có digo C# o IL.