10/07/2010 23:03
Partes del Código Objeto
Dejando ya un poco atrás la distribución del Espacio de Direcciones, hoy vamos a afrontar una distribución a menor escala: la del código objeto. Esto es necesario hacerlo por dos motivos: el Sistema Operativo se presenta como código objeto, y tendrá que estar organizado de alguna manera para que sea rápido y fácil de desarrollar; y lo mismo ocurre con las aplicaciones que se ejecuten sobre él, para que éste sepa procesarlas.
Lo primero que habría que hacer es definir por alto qué es el código objeto. La licencia LSW indica que el código objeto es "cualquier otro conjunto de datos en el que se presente la Solución Informática, de forma inequívoca, que no se ajuste a la definición de 'código fuente'"; por lo tanto, no nos cerraremos a hablar de un conjunto de instrucciones en código máquina, sino de un conjunto mayor. A nivel práctico, catalogaremos como código objeto el propio Sistema Operativo y todo aquello que se ejecute sobre él, incluyendo funciones, métodos, y también los propios datos binarios.
Quizás esto último sea un poco extraño: ¿cómo va a ser código objeto una... fotografía? Adelantaré un poco acontecimientos: en el Sistema Operativo todo van a ser funciones. Por lo tanto, abrir una fotografía sería ejecutar una fotografía.
Una vez presentada esta revelación, y antes de poner el grito en el cielo, voy a explicar cómo el concepto del Sistema de Paquetes, que ya se presentó en las jornadas anteriores, evita pensar que ejecutar una fotografía como código objeto sea una idea de locos. Esta metodología hablaba de dividir (divide et vinces) todo en paquetes (sectores, mensajes, recursos...) es una característica que tenían en común los tres niveles en los que desde el comienzo de este proyecto segmenté la informática. El código objeto no podría librarse de ser dividido. Por lo tanto, diferenciaremos tres partes en el código objeto con unos objetivos específicos:
- Cargador o lanzador: es la parte de código máquina común del código objeto.
- Se encarga de poner el área de datos en el Espacio de Direcciones.
- Está compuesto por código máquina (ejecutable) mayoritariamente.
- Cuando se invoque el código objeto se apuntará a su primera instrucción.
- Este paquete es una parte común entre instancias (funciones, métodos, datos binarios) del mismo tipo.
- Datos o imagen: es la parte donde se almacenan datos binarios.
- Incluye parámetros, constantes, espacio para variables, o demás información.
- Está compuesto por datos binarios mayoritariamente.
- Distingue dos instancias diferentes del mismo tipo.
- Código o instrucciones: es la parte de código máquina propio del código objeto.
- Está compuesto por código máquina (ejecutable) exclusivamente.
- Sirve para incluir instrucciones propias del código objeto.
Estas tres partes no tienen porqué estar necesariamente contiguas en el Espacio de Direcciones, aunque es preferible que el cargador esté compacto. El cargador está compuesto mayoritariamente de código máquina, aunque tiene algunas áreas de datos que sirven para apuntar a las otras dos partes. En los códigos máquina funcionales, los datos reservan el sitio para ubicar las variables y constantes que se utilizarán en tiempo de ejecución, mientras que la parte de código incluirá las instrucciones para la implementación de métodos y funciones.
Indicar que tanto la parte de datos como la de código tienen un tamaño constante y conocido en tiempo de compilación. Puede que sea uno de los aspectos más radicales que presentaré, por la ausencia de una estructura de pilas en el código objeto. Lo explicaré más en detalle próximamente, pero para ir entendiéndolo con el ejemplo más claro (funciones recursivas) hay que centrarse en un concepto: instancias. Todas las funciones que se ejecutan lo hacen en forma de instancia. Cuando una función a() se llama a sí misma, no se hará literalmente; en vez de llamarse otra vez a la misma a(), lo que se hace es, como cuando se cargó la propia función a(), cargar una instancia de la función a(). Por lo tanto, tendremos dos instancias de la misma función a(), en las que la parte cargador es común, la parte de datos es propia de cada una, y (en el caso de las funciones) la parte código está vacía en ambas.
Quería hacer especial mención a una característica útil del cargador en el caso de datos binarios como fotografías. Al ser una parte común, cuando se cargue por primera vez en el Sistema Operativo un dato binario de un tipo en concreto, se instalará (guardará) en el Sistema Operativo este cargador. De esta forma, se evita la redundancia y se mejora la estandarización además de otros beneficios que veremos cuando profundicemos en los datos binarios.
Comentarios
10/03/2011 14:09
Lee las entradas, participa escribiendo tus dudas, propuestas, dilemas, y le la documentación del proyecto.
Recuerda que es un Sistema Operativo desde "menos uno", tal y como indiqué en el primer párrafo de la entrada del día 2. Si deseas un Sistema Operativo desde cero, sin ser tan radical, sigue esos links.
Recuerda que es un Sistema Operativo desde "menos uno", tal y como indiqué en el primer párrafo de la entrada del día 2. Si deseas un Sistema Operativo desde cero, sin ser tan radical, sigue esos links.
9/03/2011 20:10
hola soy nuevo en lo que se refiere sistemas operativos pero me gusta el tema. solo soy un estudiante de un tecnico en informatica. barinas-venezuela. me gustaria que me orientaras mas con el desarrollo de esot. mi correo es joserond501@gmmail.com o maylo501@hotmail.com. seria de gran ayuda su colaboracion.seria de agrado que me respondiera un correo electronico. en realida los felicito esto no es nada facil y gracias por sacar un temaso como este
4/10/2010 19:44
Sí habría que programar. El SOM es un intermediario a la hora de decir qué "programa" (programado por un programador independiente) ejecutará el resto del contenido. No es algo muy diferente al actual "Abrir con..." que tienen los SO actuales, sólo que inherente en los propios archivos.
Sobre la propuesta para el SO, debatámoslo en la sección de propuestas, que para algo está.
Gracias de nuevo por tus aportaciones Frank.
Sobre la propuesta para el SO, debatámoslo en la sección de propuestas, que para algo está.
Gracias de nuevo por tus aportaciones Frank.
27/09/2010 23:59
Digamos que lo que actualmente son "el programa para ver una foto" y "la foto" en esta nueva perspectiva sería una cosa sola: los ARCHIVADORES. Esto permite que cualquier medio se pueda abrir sin necesidad de tener una aplicación independiente preinstalada, lo que ofrece una mejor y mayor accesibilidad.
El problema inherente que se te podría venir a la cabeza es el de "entonces habría un programa idéntico para cada imagen". Ahí es donde aparece 'la magia' del Sistema Operativo que se explica en el Día 20: el mecanismo de archivadores. Este mecanismo permite que si existen archivos iguales en diferentes archivadores (paquetes comunes) estos archivos se guarden de forma no redundante en estructuras del Sistema Operativo, y se enlacen en tiempo de ejecución con el resto archivos del archivador para su posterior ejecución.
Quizás es mejor que leas ese Día para comprenderlo mejor y luego, cualquier DUDA, la expongas en los comentarios.
El problema inherente que se te podría venir a la cabeza es el de "entonces habría un programa idéntico para cada imagen". Ahí es donde aparece 'la magia' del Sistema Operativo que se explica en el Día 20: el mecanismo de archivadores. Este mecanismo permite que si existen archivos iguales en diferentes archivadores (paquetes comunes) estos archivos se guarden de forma no redundante en estructuras del Sistema Operativo, y se enlacen en tiempo de ejecución con el resto archivos del archivador para su posterior ejecución.
Quizás es mejor que leas ese Día para comprenderlo mejor y luego, cualquier DUDA, la expongas en los comentarios.
27/09/2010 19:47
Sobre ejecutar una foto me parece algo peculiar, algo nuevo y no lo entiendo, yo solo se que una foto se puede ver pero no ejecutar, para querria yo ejecutar una foto? si las fotos son solo imagenes, solo se ejecutan instrucciones y eso solo lo tienen los programas.
11/07/2010 02:50
La verdad es que hoy hay bastantes cosas, como dices tú, 'revolucionarias' bajo mi punto de vista.