Creación de compilador

[julian403]

He estado viendo como crear un compilador. Y generalmente se habla del análisis léxico y sintáxico. Pero concretamente yo creo que es llevar una codificación, por ejemplo ASCII a la condificación que utiliza cierta arquitectura en cuestión, es decir, el procesador. A ver si estoy en lo correcto, denme su opinión.

Los procesadores tienen un conjunto de instrucciones, supongamos un procesador de 32 bits. Es decir, el microprocesador tiene 32 pines de entrada y 32 pines de salida. Cada instrucción tiene 32 bits, es decir, 4 bytes. No conozco ningún bytecode pero supongo que en esos 4 bytes, podría codificarse la instrucción suma. Utilizando el primer byte para codificar el tipo de instrucción, en este caso sería "suma". El segundo y tercer bytes podría utilizarse para codificar las direcciones de los registros donde se almacenan los operandos y el cuarto bytes para codificar la dirección de memoria del registro donde se almacenará el resultado.

Así, la instrucción en lenguaje máquina para la suma sería:

10001011 11010010 11100101 00010110
suma registroA registroB registroC

Ahora bien eso en el editor de C sería

C=A+B

Pero en la memoria de la pc estaría codificado en ASCII

67 61 65 43 66

1000011 111101 1000001 101011 1000010

Así que la tarea del compilador es llevar 1000011 111101 1000001 101011 1000010 a 10001011 11010010 11100101 00010110

Y a lo que me refiero con que la tarea del compilador es esa, es dejando de lado la parte que analiza los comentarios y demás.

 

[Dr. Zoidberg]

He estado viendo como crear un compilador. Y generalmente se habla del análisis léxico y sintáxico. Pero concretamente yo creo que es llevar una codificación, por ejemplo ASCII a la condificación que utiliza cierta arquitectura en cuestión, es decir, el procesador. A ver si estoy en lo correcto, denme su opinión.

Los procesadores tienen un conjunto de instrucciones, supongamos un procesador de 32 bits. Es decir, el microprocesador tiene 32 pines de entrada y 32 pines de salida. Cada instrucción tiene 32 bits, es decir, 4 bytes. No conozco ningún bytecode pero supongo que en esos 4 bytes, podría codificarse la instrucción suma. Utilizando el primer byte para codificar el tipo de instrucción, en este caso sería "suma". El segundo y tercer bytes podría utilizarse para codificar las direcciones de los registros donde se almacenan los operandos y el cuarto bytes para codificar la dirección de memoria del registro donde se almacenará el resultado.

Así, la instrucción en lenguaje máquina para la suma sería:

10001011 11010010 11100101 00010110
suma registroA registroB registroC

Ahora bien eso en el editor de C sería

C=A+B

Pero en la memoria de la pc estaría codificado en ASCII

67 61 65 43 66

1000011 111101 1000001 101011 1000010

Así que la tarea del compilador es llevar 1000011 111101 1000001 101011 1000010 a 10001011 11010010 11100101 00010110

Y a lo que me refiero con que la tarea del compilador es esa, es dejando de lado la parte que analiza los comentarios y demás.

Te doy una recomendación: seguí leyendo sobre la estructura de un compilador y de los analizadores, por que la tarea es MUCHO MAS COMPLEJA de lo que vos creés.

 

[Eduardo]

... A ver si estoy en lo correcto, denme su opinión.

Los procesadores tienen un conjunto de instrucciones, supongamos un procesador de 32 bits. Es decir, el microprocesador tiene 32 pines de entrada y 32 pines de salida.

Arrancamos mal, esa suposición no es cierta.

Cada instrucción tiene 32 bits, es decir, 4 bytes.

Tampoco es cierto. Las instrucciones pueden ser de varias palabras, es decir de 4, 8 , 12... lo que haga falta según la instrucción y la complejidad del procesador.
En caso de ser RISC, la mayoría de las instrucciones serán de 32 bits excepto las que impliquen un direccionamiento inmediato o un salto.

No conozco ningún bytecode pero supongo que en esos 4 bytes, podría codificarse la instrucción suma. Utilizando el primer byte para codificar el tipo de instrucción, en este caso sería "suma". El segundo y tercer bytes podría utilizarse para codificar las direcciones de los registros donde se almacenan los operandos y el cuarto bytes para codificar la dirección de memoria del registro donde se almacenará el resultado.

Hay diferentes opciones para realizar una suma, Si la codificación cabe en 32 bits pues será de 32 bits.
Si no, obviamente será de mas e incluso podría llegar a descomponerse en varias operaciones. Primero carga de los registros internos y después la suma. Dependerá del procesador.

Así, la instrucción en lenguaje máquina para la suma sería:

10001011 11010010 11100101 00010110
suma registroA registroB registroC

Ahora bien eso en el editor de C sería

C=A+B

Pero en la memoria de la pc estaría codificado en ASCII

67 61 65 43 66

1000011 111101 1000001 101011 1000010

Así que la tarea del compilador es llevar 1000011 111101 1000001 101011 1000010 a 10001011 11010010 11100101 00010110

Y a lo que me refiero con que la tarea del compilador es esa, es dejando de lado la parte que analiza los comentarios y demás.

En una visión mínima-mínima es esa: Generar el código de máquina.
Pero como la situación es mas compleja debido a la necesidad de directivas de compilación, ya que los diferentes bloques del programa deben ser reubicables, tener variables locales y globales y un montón de etcéteras, la generación del código de máquina se realiza en dos etapas:
- La de compilación (el compilador propiamente dicho) que produce un archivo con el código de máquina semi-terminado mas unas tablas con todas las variables y etiquetas compartidas y cuya ubicación se define al unir todos los módulos.
- La de enlace (el linker), que une todos los módulos y le escribe los valores finales.

Según el entorno utilizado y las opciones de los compiladores, estas operaciones suelen ser transparentes y muchos que se inician en esto no saben para qué sirve el linker.

 

[julian403]

Está bien, pero no me quería referir tanto a los procesos de precompilado y linkiado, ni a las diferentes compilaciones o interpretaciones que se pueden hacer según los diferentes paradigmas. Sino ser bien específicos que una compilación transforma un tipo de codificación binaria en otra. Porque cuando escribimos en el editor las instrucciones, en la pantallas aparecen la letras pero esas letras son códigos binarios (ya sea ASCII o Unicode) almacenados en la memoria y que el procesador o la tarjeta de memoria los codifica para que aparezcan los símbolos en la pantalla, manipulando la electrónica del dispositivo de salida estándar (pantalla) de manera que el símbolo aparezca en el lugar especificado, con la intensidad y tamaño especificados . Así por ejemplo ASCII, cada caracter o número ocupa 1 byte.
Así que el trabajo (básico) del compilador es levar ese conjunto de bits codificados a un conjunto de bits que interprete el procesador.

Tomando como ejemplo una máquina cuyas intrucciones sea de 4 bytes:

Así, la instrucción en lenguaje máquina para la suma sería:

10001011 11010010 11100101 00010110
suma registroA registroB registroC

Ahora bien eso en el editor de C sería

C=A+B

Pero en la memoria de la pc estaría codificado en ASCII

67 61 65 43 66

1000011 111101 1000001 101011 1000010

Así que la tarea del compilador es llevar 1000011 111101 1000001 101011 1000010 a 10001011 11010010 11100101 00010110

 

[LaElectronicaMeOdia]

Mira un compilador no es mas que pasar de un lenguaje a otro, es decir de uno de alto nivel a otro de alto nivel, o pasarlo directamente a uno de bajo nivel y despues a un "lenguaje Maquina".

a mi me parece que a estas alturas de la informatica, crear un compilador ya es una labor muy compleja o inútil cuando hay empresas con una infraestructura incompetible.

mi consejo es que si no tienes una infraestructura como microsoft, apple, etc. etc. mejor uses los que existen y crea tus propias librerias, proyectos y demas.

recuerdo que hace unos 20 años hice un lenguaje orientado a objetos que compilaba a C bastante nice debo agregar, pero fue un esfuerzo totalmente inutil.

 

[julian403]

Pero lo que intento hacer es comprender el funcionamiento de un sistema embebido, en cuanto a que el software es en última instancia la lógica en el funcionamiento de la electrónica del sistema.
No es para hacer un compilador sino para entender su funcionamiento.

 

[chclau]

como ya te dijeron en un caso muy minimo lo que decis seria cierto, pero las operaciones matematicas no se mapean uno a uno de c a lenguaje maquina. los comandos de control de flujo son mucho mas complejos en C que en lenguaje maquina. las estructuras de datos son mucho mas complejas en c que en lenguaje de maquina.

Por todo eso un programa de pocas lineas en C, en general, se traducira a un programa mucho mas extenso en lenguaje de maquina

 

[Eduardo]

Pero lo que intento hacer es comprender el funcionamiento de un sistema embebido, en cuanto a que el software es en última instancia la lógica en el funcionamiento de la electrónica del sistema.
No es para hacer un compilador sino para entender su funcionamiento.

Si te interesa, pegale una leída a la "The SPEW Assembler Compo".

Se trataba de una competencia de programación en assembler x86 (gana el mas corto) en la que había que escribir un ensamblador para un procesador ficticio (algo de pocas instrucciones, justo para competencia).


Te recomiendo que trates de escribirlo y después compares con lo hecho por los competidores. No solo te va a asombrar lo monstruos que son sino que además vas a entender como funciona realmente un compilador.