Versión HTML por Nacho Cabanes
Existen dos grandes áreas para el diseño de programas
de ordenador:
La primera, se encarga de cómo la información va a
ser tratada dentro de un sistema, en contraposición a la programación
de gestión que se encarga más bien, de cómo se representa
y se trata la información dentro de un programa.
Pongamos un ejemplo. A un programador de gestión cuando guarda un valor en una variable, sólo le interesa saber dónde guarda ese valor, en una variable independiente, en una lista, una tabla, un árbol..., sin embargo, a un programador de sistemas también le puede interesar saber cómo se guarda ese valor, en qué dirección de memoria, con qué formato...
Otra característica que diferencia ambas áreas, es que la programación de aplicaciones, por así decirlo, es universal y los métodos que se usan pueden ser utilizados para cualquier tipo de máquina, al contrario que la programación de sistemas, que depende de la máquina sobre la que se va a trabajar, y antes de embarcarse en cualquier proyecto es necesario conocer el hardware del que se dispone.
De la programación de gestión no os hablaré más, ya que está orientada a otros fines que no son los que nos interesan. Unicamente comentaros que aunque conozco algunas excepciones (en Clipper con rutinas en C y asm), la verdad sea dicha, los lenguajes de gestión no están hechos para los gráficos. Como ejemplo os diré que en RPG y COBOL, (dos lenguajes que estoy aprendiendo), no es que no se pueda trabajar con gráficos, noooo, ¡¡Es que no se puede hacer ni una dichosa línea!!. X-O
Bueno volvamos a lo nuestro que me exalto. ;) Que la programación de sistemas esté tan ligada al hardware, no significa que para programar tengamos que 'ponernos el mono' y empezar a trabajar con los puertos de las tarjetas, nosotros también contamos con ayuda para no tener que 'ensuciarnos las manos', pues existen varias interfases software, como la BIOS (Basic Input Output System) y el Sistema Operativo (MS-DOS en nuestro caso), que nos ayudarán a realizar nuestra tarea.
La forma con la que tenemos que ver un ordenador es la siguiente:
---------------------------
| Sistema Operativo |<----
------------
| ------------------- |
| Programa |
| | BIOS
|<-------- | de |
| | ----------- | |
| usuario |
| | | Hardware <------------ ------------
| | ----------- | |
| ------------------- |
|------------------------ |
Es decir, el corazón de todo ordenador es el hardware del que se compone, pero para gestionar todas las posibilidades de la máquina y protegerla de nuestra manazas, surgieron las interfaces que nombramos antes. Estas son como caparazones que envuelven el hardware y que van ofreciendo los servicios de niveles internos, a los niveles más externos, proporcionando más seguridad, aislando el tipo de hardware y facilitando el acceso, pero como todo no van a ser ventajas, esto lleva un gasto de tiempo que puede ser necesario evitar.
Al trabajar con un ordenador, (me refiero a programarlo), no es obligatorio pasar por todos los niveles para utilizar el HW, podemos evitar el uso de algún nivel y acceder directamente a los servicios de los niveles más internos. Para decidir cuál de los niveles utilizar, primero tendremos que pensar que objetivo buscamos: velocidad, optimización del tamaño del programa, seguridad, independencia del hardware. ¿Lo mejor? trabajar siempre en ensamblador y a nivel hardware, pero 'casi' siempre no vale la pena. ¿Os imagináis qué se esconde detrás de ese casi...? ;) pues sí, la programación de buenos videojuegos y, en general, aplicaciones que necesitan un máximo aprovechamiento de la velocidad del procesador.
Existe un factor llamado 'overhead', cuyo valor es indicativo del tiempo gastado en pasar entre dos niveles adyacentes de los ya comentados, que nos dirá si vale la pena romperse la 'head' bajando a las capas más internas; si ese factor es pequeño, no te compliques la vida y sé feliz, ;) utiliza los niveles más externos y sin problemas, pero si ese valor es muy grande (que lo suele ser), vamos a tener que calentarnos la cabeza, Oo·:( y aprovechar al máximo las posibilidades de la máquina. Muchas veces no es necesario tener en cuenta ese valor y basta con fijarse en otros aspectos del programa que queremos realizar, un ejemplo, imaginaros que vamos a hacer una utilidad que trabajará con diskettes, para qué vamos a utilizar programación de muy bajo nivel, para ahorrarnos unos -->segundos<--- de overhead, si el acceso a disco de por sí ya es leeeento. Otra cosa sería estar trabajando con aplicaciones de video, donde ahorrar tiempo puede significar permitirte, o no, hacer una animación de más de 10 imágenes por segundo.
Bueno, con ésto ya acaba... (¿me ha parecido oír
algunos suspiros y gritos de alegría?. Seguro que no, sois buenos
alumnos y no me habéis interrumpido ni una vez JE JE) :)) , este
capítulo dedicado a la programación de sistemas. Todo esto
sería paja si no os mostrase algún ejemplo de verdad, donde
podáis apreciar ese overhead del que os he hablado. En el artículo
del modo 13h, tengo previsto poner un ejemplo de la DIFERENCIA de utilizar
unos servicios u otros, además, y ésto no estaba previsto,
hablaré un poco de los conceptos y herramientas necesarias para
trabajar en cada nivel en el artículo La cacharrería.
