Un recompilador binario es un compilador que toma archivos binarios ejecutables como entrada, analiza su estructura, aplica transformaciones y optimizaciones y genera nuevos binarios ejecutables optimizados. [1]
Las bases de los conceptos de recompilación binaria fueron establecidas por Gary Kildall [2] [3] [4] [5] [6] [7] [8] con el desarrollo del traductor de código ensamblador optimizador XLT86 en 1981. [4] [9] [10] [11]
[…] "A menos que tengas un esquema de traducción que tenga en cuenta las idiosincrasias peculiares del microprocesador de destino, no hay forma de que un traductor automático pueda funcionar", explica Daniel Davis, un programador de
Digital Research
. "Terminarás con
transliteraciones
directas ". […] A pesar de todas estas limitaciones, recientemente se ha avanzado en el desarrollo de traductores. En particular, Digital Research ha presentado su traductor de código ensamblador de ocho a dieciséis bits. Según la investigación realizada por el presidente de Digital Research,
Gary Kildall
, el
XLT86
parece ofrecer avances sobre la tecnología de traductores de software disponible anteriormente. Al igual que
Trans
de
Sorcim
y
Convert 86
de
Intel
, el paquete de Kildall traduce código en lenguaje ensamblador de un
microprocesador
8080 a un
8086.
Sin embargo, Kildall ha aplicado una técnica
de análisis de flujo global
que tiene en cuenta algunas de las principales desventajas de otros traductores. El procedimiento analiza el uso de registros y banderas en secciones de código 8080 para eliminar
código no esencial
. Según el programador de Digital Research, Davis, el algoritmo que utiliza Kildall permite al traductor considerar el contexto a medida que traduce el programa. Hasta ahora, uno de los principales problemas con cualquier programa traductor ha sido la incapacidad del software para hacer mucho más que la transliteración. Si el nuevo traductor de Digital Research realmente hace avanzar la tecnología hasta el punto en que se pueda considerar el contexto, entonces es posible que proliferen más traductores de software en el mercado de las microcomputadoras.
marzo de 1995, la
Asociación de editores de software
honró póstumamente
a Gary
por sus contribuciones a la industria informática. Enumeraron algunos de sus logros: […] En la década de 1980, a través de
DRI
, presentó un recompilador binario. […]
[…]
Rolander
: Mencioné antes que
a Gary
le gustaba abordar un problema como arquitecto. […] Y dibujaba las imágenes más hermosas de sus estructuras de datos. […] Y cuando terminaba eso […] y estaba convencido de que esas estructuras de datos ahora eran correctas, entraba en un modo de codificación maníaco increíble. Él podía estar hasta 20 horas al día [...] simplemente no estaba durante esos períodos de tiempo. En un par de esas ocasiones, cuando conseguía que algo funcionara por primera vez, lo que podía ser en mitad de la noche. Y todos los que han escrito software han visto, por ejemplo, que la primera vez que aparece en la pantalla, tienes que decírselo a alguien. Mi esposa Lori les dirá que recibí un par de esas llamadas en mitad de la noche,
LOGO
fue un ejemplo,
XLT 86
fue otro, donde lo puso en funcionamiento la primera vez, y tuvo que hacer que alguien lo viera. Así que no importaba la hora que fuera, él me llamaba, tenía que ir a verlo en funcionamiento. [...][2][3] (33 páginas)
[…]
XLT-86
es un programa traductor analítico escrito en
PL/I-80
. Lee todo el programa fuente
8080
, lo ensambla en
código de máquina
, analiza la utilización de registros, memoria y banderas, y emite un programa en lenguaje ensamblador
8086
optimizado . […] La traducción del programa se realiza en un proceso de cinco pasos. Primero, el programa se escanea y ensambla para producir valores y ubicaciones de símbolos. Segundo, se analiza la estructura del programa y se descompone en
bloques básicos
. Tercero, se analizan los bloques básicos para determinar
el flujo del programa
y el uso de recursos. En cuarto lugar, la
estructura de bloques
y los datos
de asignación de registros
se recopilan en una lista para el usuario. En quinto lugar, la información de flujo y el programa fuente se utilizan para generar el programa fuente 8086. […]
[…] Kildall: […] Hace un año y medio probablemente dedicaba el 75% de mi tiempo al negocio y el 25% a la programación.
XLT-86
era un producto en el que estaba trabajando en ese momento, y me llevó nueve meses hacerlo. Ese habría sido un proyecto de tres meses si hubiera podido concentrarme en él. […]
[…] PC: ¿Cuáles son algunas de las complejidades involucradas en la traducción de un programa del
formato
8080
al
8086 ?
Kildall
:
Las traducciones directas a nivel de programa fuente
se pueden hacer de manera bastante mecánica. Por ejemplo, una instrucción "Agregar 5 inmediato" del 8080 se convierte en una "Agregar AL 5" en el 8086: una traducción muy sencilla de los propios códigos de operación. La complejidad de
la traducción mecánica
surge de situaciones como esta: la instrucción 8080 DAD H toma el registro HL y le añade DE. Para el 8086, la instrucción equivalente sería algo como ADD DX BX, lo cual está bien, no hay ningún problema en particular. Simplemente se dice que el registro DX es el mismo que HL y BX es el mismo que DE. El problema es que la instrucción 8086 tiene un efecto secundario de establecer el indicador cero, y la instrucción 8080 no. En la traducción mecánica se termina haciendo algo como guardar los indicadores, restaurarlos, hacer algunos cambios y rotaciones, etc. Esto agrega alrededor de cinco o seis instrucciones adicionales para obtener el mismo efecto semántico. Hay muchas secuencias en el código 8080 que producen secuencias muy extrañas en el código 8086; simplemente no se asignan muy bien debido a los registros de indicadores y cosas de ese tipo. La forma en que pasamos el software es algo llamado
XLT-86
. Ha estado en el mercado seis meses más o menos. PC: ¿Por código "mejor" se refiere a un código más pequeño? Kildall: Un veinte por ciento más pequeño que si simplemente tomara cada código de operación y hiciera una traducción directa, guardando los registros para preservar la semántica. PC: ¿Cómo se compara el tamaño del programa traducido con la versión 8080? Kildall: Si toma un programa 8080, lo traslada al mundo 86 y realiza una traducción XLT-86, encontrará que es aproximadamente entre un 10 y un 20 por ciento más grande. Con máquinas de 16 bits es más difícil abordar todo; se obtienen códigos de operación que son un poco más grandes en promedio. Un fenómeno interesante es que una de las razones por las que no se obtiene un aumento tremendo de la velocidad en el mundo de 16 bits es porque se ejecutan más códigos de operación sobre el bus de datos. […]