Compilación de programas en micro y en SO

[julian403]

Tengo una duda teorica sobre la programación. El lenguaje C es un lenguaje con símbolos y reglas. Puedo escribir un programa en un papel con un lapiz que sea sumar dos números enteros y que alguien ejecute ese algoritmo por ejemplo

int a, b;

a=25; b=5;
printf("%d", a+b);

entonces alguien al ejecutarlo tendrá que hacer la suma y mostrala. Ahora cuando queremos que ese algoritmo se ejecute en un circuito electrónico necesitamos de un compilador.

Pero hay dos posibles circuitos electrónicos que se pueden programar, un microcontrolador y una PC. En el caso del microcontrolador el compilador llevará ese algoritmo a código máquina, es decir, en manera fácil, dispondrá 2 registros generales en los cuales establecerá los valores númericos 25 y 5, pasará esos datos a un circuito sumador en la ALU y luego al resultado lo dispondrá en un tercer registro.
En cambio cuando realizamos ese programa para que corra en la consola de windows, el compilador no generará un código máquina para el procesador, sino que tengo entendido que al programa en C lo llevará a una códificación de llamadas al SO. Es decir, a diferencia de lo que hace con el microcontrolador de manera de hacerlo funcionar ahora el compilador lo que hace es pasarle las instrucciones al SO de manera de que este maneje el hardware.

¿es correcto eso? o estoy equivocado.
Saludos.

 

[Miembro eliminado 356005]

No es exactamente así.

El proceso de compilado lo que hace es traducir el código fuente a código máquina de la arquitectura destino. Da igual que sea un µprocesador o un µcontrolador. Según la arquitectura destino, el compilador sabe de cuántos registros dispone para realizar las operaciones.

En el ejemplo que pones, además, depende del compilador darse cuenta de si va a necesitar dos registros, dos posiciones de memoria, uno de cada, o incluso ninguno (un compilador moderno se daría cuenta de que puede enviar, directamente, un valor de 30 a la rutina printf).

En el caso de Windows es lo mismo: se genera un código máquina, pero... no es lo mismo realizar un programa para la consola que para Windows. En el caso de la consola, se está bajo una simulación del antiquísimo MSDOS, en donde las operaciones más básicas (por ejemplo, sacar un texto en pantalla) se realizaban como llamadas al SO.

En cuanto a tu pregunta, sí que vas bien encaminado: el µcontrolador guardará el resultado en un registro de la CPU o en la RAM (o EEPROM). En el caso de un microprocesador, el resultado también quedará almacenado en un registro o memoria. Es cuestión, luego, de que existan instrucciones adicionales, para que lean ese registro y llamar al SO para que salga el resultado en pantalla (que, a bajo nivel, se traduce en enviar los caracteres a la "pantalla", que en realidad es enviar bytes a determinadas posiciones de la RAM de pantalla).

 

[julian403]

No entendí bien. En el caso de un microcontrolador este no posee un sistema así que lo único que habrá en su memoria ROM será este programa compilado. En el caso de tener un SO, ¿como interviene este? supongo que cuando se ejecuta un programa este dispone la memoria ram y ahí ¿el programa corre por si mismo? o ¿el programa lo que hace es llamadas al sistema para que este realice las tareas?

 

[Miembro eliminado 356005]

Los sistemas microcontroladores son muy sencillos: grabas el programa en memoria Flash, y cuando el micro recibe alimentación o se reinicia, comienza la ejecución del programa en la dirección 0 (o en la que tenga predefinida).

En el caso de un sistema más complejo, el SO es el encargado de leer el programa desde la memoria de masa (el disco duro, por ejemplo), reservar memoria para él, colocarlo, y comenzar a ejecutarlo. Y, claro, en un sistema complejo, un programa no 'suele' realizar todas las operaciones por sí mismo. En estos sistemas, el hardware queda aislado del resto de programas por medio del SO.

Más información.

 

[julian403]

Igualmente no encuentro una respuesta concisa. Por lo que te entiendo en un microcontrolador un compilador genera el código máquina y lo guarda en su memoria ROM (flash por ejemplo), el comienzo de su código está en la posición de memoria 0h (no quiere decir que sea la posición 0 física), dependiendo del micro habrá diferentes set de instrucciones pero hablando por hablar supongamos que en la primera dirección está el tipo de operación a realizar y lo guarda en un registro, luego las 2 siguientes direcciones serían por ejemplo los datos que se guardan en los registros Ax y Bx, en el siguiente pulso de clock se realiza la operación y se guarda en un tercer registro Cx y en el siguiente clock sale por los pines de salida.

Ahora en un sistema con SO, se hace la llamada de la ejecución de un programa que está en una cierta dirección del disco duro. Supongamos que en la primera dirección está la cantidad de ram que va a utilizar y el SO se la asigna. Y luego entiendo que puede haber 3 posibles casos.

1) el programa corre el mismo en la circuitería, ya que el SO le dió los permisos, le asigno la memoria necesaria, etc, es decir, le facilitó y le dió la posibilidad del manejo del hardware.
2) Que el programa lo que en verdad haga es hacer llamadas al sistema operativo para que este maneje el hardware y realice el las instrucciones (máquina estendida).
3) un poco de ambos, es decir, hay ciertas cosas que el programa aplicación maneja el hardware y otras cosas que el SO maneja el hardware y el programa le dice que es lo que tiene que hacer al SO.

Saludos.

 

[analogico]

cuando compilas para un sistema operativo compilas en un formato con informacion adicional
para que el loader del sistema operativo cargue el programa a memoria


en dos se compila en formato MZ y COM
en windos a formato PE
y en linux a formato ELF

En el caso de la consola, se está bajo una simulación del antiquísimo MSDOS, en donde las operaciones más básicas (por ejemplo, sacar un texto en pantalla) se realizaban como llamadas al SO.

eso solo si el programa es un MZ o un COM
los programas antiguos funcionaban mas al hardware


en un programa mas nuevo si es grafico o de consola es casi lo mismo

 

[chclau]

Cuando uno programa en C, normalmente al final se usa un compilador. Un compilador SIEMPRE genera codigo de la maquina que lo ejecuta, ya sea el micro de un PIC o el super procesador de una PC.

El SO no tiene nada que ver con el modo en quie se ejecuta el codigo. El SO lo que entrega son servicios de administracion de los recursos del sistema, desde el disco rigido, los USB y la conexion de LAN, pasando por las memorias del sistema y hasta el tiempo mismo de ejecucion de las tareas en el micro.

Un SO puede estar involucrado en codigo ejecutado luego de compilacion, luego de interpretado, o incluso en hibridos como Java. A lo que voy es que usar o no SO no influye en el modo en que se convierte el lenguaje de alto nivel en codigo maquina. Solo influye en como accede dicho codigo a los recursos del sistema.

 

[miborbolla]

Los Sistemas operativos tienen previsto un "Shell" o "Framework" para el propósito de ejecutar programas y así se asegura; el poder brindar todos sus servicios dentro de un marco de seguridad que no afecte (en la medida de lo posible) al propio sistema operativo, estos programas que pueden ejecutarse bajo el Shell o Framework se conocen con el nombre de software. Mientras que en un "ambiente" de un Microprocesador/microcontrolador (hardware puro ) se parte de un Datasheet y simplemente no existe quien administre los recursos y todo queda en la responsabilidad de quien programe el firmware.

Por todo esto, es que se han desarrollado los Compiladores de lenguaje de alto nivel que son los encargados, dependiendo de la plataforma de destino, para generar el código "ejecutable" correspondiente; ya sea para un sistema operativo (Software) o un sistema de hardware puro (Firmware).

Por estas razones, es muy superficial intentar comparar los resultados de la compilación entre estos dos conceptos (Software y Firmware).

Saludos

 

[julian403]

¿El firmware de una Pc sería el SO?

 

[Miembro eliminado 356005]

El firmware de un PC es su BIOS.

Te enlacé con la página de Wikipedia sobre lo que era un Sistema Operativo. Te recomiendo su lectura, calmada. También tienes la página sobre firmware.

 

[julian403]

Bien, el firmware es un conjunto de códigos en una memoria ROM, que maneja físicamente el hardware. La BIOS se encarga de controlar que todo esté conectado mediante un checksum o SCR y carga el SO desde el disco duro hacia la RAM, es decir, una parte del código de la BIOs debe ser, cargar desde el disco de tal a tal cluster o sector en la ram y listo y esto lo hace moviendo el motor paso a paso del disco hasta una posición determinada, activando el chipselect de escritura en uno de los integrados del banco de meoria del buffer y poniendo una dirección en el bus de direcciones junto con el dato en el bus de datos, esto lo hace en cada pulso de clock hasta leer todo el sector y luego el mismo procedimeinto de escritura del buffer a la ram. Aunque quizás el buffer puede ser registros (flipflops) de ahí pasarlos a un banco de memoria como la ram.

Pero, si el firmware maneja el hardware. Como un programa como el navegador puede visualizar las cosas en la pantalla. Porque en un punto lo que hay que manejar es la circuitería del procesador y/o la placa de video y eso es hardware; así que en el último punto se tendría que encargar el firmware de manejar los niveles de tensiones, adaptarlo si es necesario (ya que la placa de video puede trabajar con otras tensiones), de cargar esos niveles de tensiones en el memoria de video, activando los chipselect de escritura, posicionando los datos en el bus de datos y las direcciones en el bus de direcciones, realizar las operaciones para llevar dicha codificación (quizás de ASCII o Unicode) a una codificación RGB mapeada en la pantalla, según una configuración de antemano establecida (ya sea de 640x880 o de 1024x760) de manera que el procesador deberá no solo decodificar sino también tener en cuenta el mapeo de pixeles; todo esto controlado por pulsos de clock.
Y como el SO no maneja el hardware y muchos menos el navegador el cual es un software de aplicación, ¿Qué es lo que hace estas operaciones?.

O por ejemplo, otro programa de aplicación como el editor de texto de LibreOffice, terminé de escribir y pongo guarda. Entonces se activará el chipselect de lectura de la ram a la vez que se posicionan las direcciones de memoria del dato que voy a leer de esta y en el siguiente pulso de clock aparece el dato en el bus de datos hacia un registro (el cual por supuesto tiene el mismo bus de datos y activado su escritura), todo esto hasta que se complete todas las direcciones de memoria y lectura de las misma en las posiciones donde están los datos del editor de texto, luego del buffer pasa al disco. ¿Quién hace todo esto el editor, el SO ? ¿quien le dice cuando pongo guardar que se active la ram en lectura, y quien le pasa las posiciones de memoria de los datos a leer?

¿otro ejemplo? el juego conter strike, va generando 2 datos aleatrorios que son la posición de un terrorista en la pantalla x, y (por ejemplo), cada dato es de 8bit y se guarda en la ram, esos datos van cambiando en cada pulso del procesador. Despues tenemos el mouse que al moverse va dando 2 datos, la posición x y la posición y (dejando de lado la comunicación serie y todo eso) a esos 2 valores del mouse lo guarda en otras posiciones de la ram. Cuando se hace click derecho este manda una señal de control al micro y lee una posición de memoria, en esa posición de memoria es una microinstrucción que compare la posición del terrorista con la del mouse si son iguales obtenemos un dato, si no son iguales otro (todo esto dejando de lado que los datos de la ram pasan a los registros internos del micro antes de las comparaciones, sumas, etc). Con el dato de que sean iguales, activa mediante una señal de control la placa de sonido en lectura y le manda el dato por el bus de datos a esta, esta lo decodifica y lo pasa a un conversor CDA y sale en el parlante un grito del terrorista muerto. ¿Quien hace todas estas operaciones? ¿el juego? ¿el SO? ¿los controladores que serían los firmwares?

Saludos.

 

[Miembro eliminado 356005]

El SO sí maneja el hardware, a través de los controladores (drivers) que el propio SO ha cargado en el momento del arranque.

Cuando pulsas Guardar en el Libreoffice, esta aplicación ejecuta llamadas de tercer nivel al SO de que quiere guardar un contenido con un nombre, en una determinada posición del sistema de ficheros. Las llamadas de tercer nivel se traducen en llamadas de segundo nivel en donde se resuelve cosas como por ejemplo si el archivo va a ser sobreescrito, o en qué disco duro se va a escribir o si hay espacio suficiente. Estas llamadas se transforman en llamadas de primer nivel, en donde el SO puede hablar con el controlador del sistema de ficheros para indicarle el nodo dentro del árbol del sistema de archivos donde guardará físicamente el archivo, y que reciba el contenido y lo cierre. El controlador traduce todas esas peticiones a llamadas de bajo nivel en la que intercambia comandos de órdenes con el disco físico y devuelve un valor de éxito o fracaso.

Pero no hay control de las señales electrónicas ni tensiones en el bus ni nada parecido. La electrónica de un sistema está preparada para servir inmediatamente a las peticiones de la BIOS o de los controladores. Ni siquiera la CPU es "consciente" de las señales de reloj de las operaciones de lectura/escritura en la RAM. La CPU vive en un entorno en donde se supone que todo eso ya está funcionando y no tiene que preocuparse de nada físico. Todas las tareas de relojes, sincronizar entre periféricos, hacer de árbitro cuando dos o más periféricos quieren acceder al bus... eso es lo que llamamos hardware. Si quieres darle un nombre o buscar un responsable, llámalo Chipset.

 

[julian403]

A algo así me refería. Si sé que el chipset se encarga de adapatar los niveles de tensión entre los dispositivos que manejan tensiones diferentes y a su vez de adaptar las frecuencias de trabajo, ya que la frecuencia del micro es mucho mayor a la de la mayoría de los dispositivos y hay que bajarla un poco y esto los hace mediante divisores de frecuencia con flipsflops, no me acuerdo bien cuales eran si las clases D o T.

Pero bien, entonces los controladores o drivers manejan el hardware. Y supongamos que cuando un programa hace una acción como la de guardar, realiza un cambio en algún registro, que llama a un conjunto de datos en una cierta dirección que son instrucciones del SO, que a su vez en esas instrucciones del SO hay un dato y/o dirección que llama a instrucciones del controlador, que ya son ejecutables por un dispositivo en cuestión.
Se podría decir, que una instrucción del editor de texto se va codificando (o decodificando dependiendo de como lo mires) en otras instrucciones, que dan paso a otras y asi hasta llegar a unas que ya manejan el disco.

 

[julian403]

Digo esto porque de la forma que lo pronuncian, el SO parece que es un ente que vive en la cpu (quizás así se lo enseñaron y yo investigando parece que así es como lo interpretan pero yo quiero llegar más profundo) y la verdad que no es así. Si ejecuta instrucciones es debido a que hay en la memoría un conjunto de bit y la unica forma de que se haga una acción es que el microprocesador las interprete y convierta. Cuando se dice que el sistema operativo hace llamadas, sería que se ejecutan instrucciones que se van decodificando hasta una que pueda ser interpretada por la placa de video,, de sonido , etc. o no?

 

[Miembro eliminado 356005]

El SO no vive en la CPU. Está en la memoria RAM y fue cargado en el momento del arranque del sistema.

Y sí, la CPU va ejecutando tanto programas como el SO, y cuando se trata de operaciones que tienen que dialogar con los periféricos, se hacen llamadas a través de los puertos de E/S del espacio de direcciones reservado para ello.

 

[chclau]

El SO no es un ente, es un conjunto de programas y rutinas. Pero hay un enorme pero, y es que el SO suele tener acceso a recursos del sistema a los que las aplicaciones comunes no tienen acceso.

Por ejemplo, el SO puede decidir de que manera repartir el tiempo de procesamiento entre las diversas tareas y o aplicaciones que estan corriendo en el sistema.

la placa de audio no decodifica Instrucciones, tampoco la de video, el unico que decodifica instrucciones es el micro. El unico caso en que alguien, aparte del micro, decodifica instrucciones, es cuando hay en el sistema coprocesadores (y si, hoy en dia muchisimas placas de video tienen procesadores con instrucciones dedicadas, por ejemplo, a la generacion de imagenes en 3d)

estas haciendo preguntas muy complejas cuya cabal comprension requiere mucho estudio, en particular y en mi caso te puedo decir que mi conocimiento sobre SO es teorico porque jamas escribi una linea de un SO. Se requiere programadores muy cualifcados para meterse en eso. De todos modos te recomendaria que busques libros sobre arquitectura interna de micros para empezar, para aclarar conceptos sobre como funciona un micro, que es la decodificacion de instrucciones, etc.

otra aclaracion mas, la adaptacion de velocidad del micro a la jerarquia de perifericos no se hace con un simple divisor de frecuencia a FFs, es otro tema complejo que dio lugar al nacimiento de una enorme familia de bichos de HW, como ser, memorias cache, bridges o puentes (a nivel de HW, no confundir con bridges de comunicaciones), arbitradores, controladores DMA, FIFOs y un largo etc.