A lo largo de esta serie hemos visto cómo funciona un ordenador, empezando por sus componentes más básicos, los transistores, y subiendo cada vez más en abstracción hasta llegar al sistema operativo y los programas de usuario.

He intentado cubrir todo el camino completo, pero sin entrar en demasiado detalle en ninguno de los artículos (si alguien quiere más detalle de algo concreto, que lo pida y veremos qué se puede hacer), pero permitiendo seguirlo a alguien sin conocimientos previos (espero… esa era al menos la intención).

No obstante, por si alguien quiere profundizar, vamos a dejar algunas referencias a textos más profundos. No conozco ningún texto que cubra todo el camino en profundidad, porque cada una de las áreas que cubre esta serie es complicada en sí misma, así que tendré que dar varias referencias.

Para la parte inicial es útil algún libro de electrónica. Yo he utilizado (tanto para esta serie como cuando lo estudié hace ya unos añitos) el libro “Microelectrónica” de Jacob Millman y Arvin Granbel. Cubre más o menos desde el principio hasta la lógica secuencial.

Para la parte media, el mejor libro que conozco es “Curso de ordenadores: conceptos básicos de arquitectura y sistemas operativos”, de Gregorio Fernández. Tanto es así que los ordenadores C16 que hemos visto aquí se basan en lo que Gregorio usa en su libro.

Para la parte final, la de sistemas operativos, es muy interesante el libro ”Operating System Concepts” de A. Silberschatz y P. Galvin. Otro muy bueno es ”Operating systems: design and implementation” de Andrew S. Tanenbaum; probablemente no es el mejor, pero Andrew escribe muy bien, y además te da su propio sistema operativo, Minix, para que vayas viendo en el código lo que te cuenta en la parte teórica.

Fue un placer.

Ya hemos visto a lo largo de la serie cómo funciona el hardware de un ordenador, hemos visto más o menos qué hace un sistema operativo y cómo lo hace… solo nos queda ver cómo empieza el mundo: yo le doy al botón de encendido en el ordenador y entonces ¿qué ocurre?

El problema de explicar esto es que, aunque hay cosas comunes, cada ordenador y cada sistema operativo es diferente. Así que vamos a centrarnos en los sistemas que más utilizamos en casa: los PCs con MS Windows.

Todo empieza cuando el usuario le da al botón de encendido. Todos los microchips del ordenador reciben alimentación y empiezan a funcionar. En particular, la CPU empieza con su ciclo: mira la dirección de memoria a donde apunta PC (recordad: el Program Counter) y ejecuta lo que haya ahí… así una y otra vez.

Así que, como acaba de empezar, lo que hará es ejecutar lo que haya en la posición 0×00000000. ¿Qué hay ahí? En los ejemplos que hemos visto hasta ahora lo que había ahí era nuestro programa, pero claro, ahora queremos algo más versátil, un PC de escritorio normal y corriente, así que no podemos esperar que ahí esté precisamente el programa que quiere ejecutar el usuario.

Lo que hay ahí es la BIOS.

BIOS significa Basic Input-Output System (sistema de entrada-salida básico)^[1] y lo que es es un programa, proporcionado por el fabricante del ordenador, que tiene lo básico para arrancar. Y está en esa posición 0×00000000 porque el fabricante la ha puesto ahí adrede.

BIOS típica de un PC (Flickr de CaneHappy, cc-by-sa-2.0)

Esa BIOS, nada más arrancar, configura el puntero de la pila (para poder manejar interrupciones y subrutinas a partir de ahora) y empieza a ejecutar su programa:

• Configura el vector de interrupciones para atender ella todas las interrupciones
• Hace un análisis básico del hardware que tiene el ordenador: comprueba cuánta memoria tiene, qué discos, qué tarjeta gráfica…
• Arranca el cargador de arranque (veremos esto luego)

¿No os parece que hace muchas cosas que hace el sistema operativo? Bueno, no del todo. De todo lo que hacía el sistema operativo, la BIOS prácticamente solamente sabe hacer la gestión de los dispositivos, y además solo de un conjunto muy limitado de ellos: teclado y pantalla básica; a veces también ratón o tarjeta de red.^[2]

El caso es que la BIOS ya se está ejecutando y tratará de “arrancar” de un dispositivo. Esto se puede configurar, pero lo normal es que acabe arrancando de un disco duro. Así que lo que hace es irse al primer sector del disco duro seleccionado, leer todo lo que hay ahí y ponerlo en memoria. Eso es lo que se llama el “sector de arranque” del disco.

¿Y qué es lo que hay en ese sector de arranque? Pues lo que el usuario haya puesto ahí, claro… pero lo normal es que ahí haya un cargador de arranque (en inglés, bootloader).

¿Qué es el bootloader? El bootloader es otro programa, proporcionado por el fabricante del sistema operativo, que sabe cómo arrancar dicho sistema operativo. Bootloaders habituales en el mundillo Linux son LILO o GRUB; en el mundillo Microsoft probablemente ni siquiera seas consciente de que existe este cargador, porque no lo ves, pero también existe.

Así que de una forma u otra, el bootloader ha arrancado al sistema operativo (en nuestro ejemplo, alguna de las versiones de MS Windows). El sistema operativo, cuando arranca, configura su propio vector de interrupciones (eliminando la configuración que había puesto ahí la BIOS), detecta y configura todos los dispositivos que tiene, inicializa los módulos de gestión de procesos, de memoria y el sistema de ficheros y finalmente crea unos cuantos procesos: el gestor de impresiones, el de logon, el de red, el indexador… en fin, muchos procesos. Fíjate en que todos estos procesos son importantísimos, porque sin ellos el sistema operativo queda cojo, pero desde el punto de vista del módulo de gestión de procesos son un proceso más, no son diferentes de los procesos que ejecutará el usuario más adelante.

Uno de esos procesos será el encargado del logon del usuario, que típicamente le pedirá al usuario un nombre y una contraseña a través del teclado. El usuario mete su nombre y su contraseña y el sistema lanza otro montón de procesos… pero ahora esos procesos pertenecen al usuario. Entre ellos, ejecutará algún tipo de intérprete de comandos. Antiguamente, el intérprete de comandos era una línea de comandos, textual, en la que el usuario iba poniendo órdenes con el teclado; ahora lo normal es que esos comandos se den de forma gráfica, señalando con el cursor del ratón a un icono y haciéndole doble click, o algo similar.

El caso es que el usuario hace doble click en el icono del Buscaminas y el sistema operativo arranca el Buscaminas.

Buscaminas de Microsoft

¿Y qué significa eso de arrancar el Buscaminas? En un capítulo muy muy lejano dijimos que no te preocuparas de cómo llegaban a la memoria los programas, que lo explicaríamos más adelante… bueno, pues el momento ha llegado… y estoy seguro de que eras capaz de deducirlo tú solo. Atento, porque esto no es solo la forma en que se carga el Buscaminas, sino cualquier otro programa, incluidos los que hemos visto que se lanzan durante el arranque del sistema operativo.

En realidad es muy sencillo: cuando se quiere cargar un programa, el módulo de gestión de procesos crea un proceso. Luego se lee el contenido del fichero ejecutable del disco (utilizando los servicios del módulo de sistema de ficheros, que a su vez utilizará los del sistema de gestión de dispositivos) y lo escribe en memoria principal (utilizando los servicios del módulo de gestión de memoria). Finalmente, se configura el contador de programa del proceso para que apunte al área de memoria recién escrita… et voilà! La próxima vez que le toque el turno a este proceso, ejecutará las instrucciones que había en el fichero ejecutable.^[3]

Y ya está: ya puedes jugar al Buscaminas hasta que te canses; en ese momento decidirás cerrar el programa (seguramente haciendo click en la “x” de la parte superior derecha de la ventana), y en ese momento el programa informa al sistema de que debe finalizar. El sistema operativo, en concreto su gestor de procesos, elimina entonces la entrada que hacía referencia al programa de la lista de procesos, y el programa desaparece… hasta que vuelvas a hacer doble click en su icono, cuando todo vuelve a comenzar.

En el próximo (y último capítulo) veremos un resumen y daremos referencias para quien quiera profundizar.

1. Aunque “sistema” es masculino, y por lo tanto también debería serlo BIOS, todo el mundo dice “la BIOS”, en femenino… no sé por qué.
2. No obstante, sí es verdad que las BIOS modernas empiezan a ser cada vez más sofisticadas, incluso con navegadores web y sistema de ficheros.
3. En realidad nos hemos saltado un paso intermedio, en el que el proceso creado es una copia del que lo creó, pero para el nivel de este artículo eso no es necesario.

En el último capítulo de esta serie vimos la evolución histórica de los sistemas operativos, y vimos cómo nacían los cuatro componentes más importantes de los sistemas operativos. Lógicamente, no todos los sistemas operativos son iguales. No es lo mismo el sistema operativo de un mainframe que el de tu Nintendo DS, el del cajero automático del banco que el de tu teléfono móvil, el de los servidores de Amazon que el que lleva tu televisor… pero casi todos ellos comparten un conjunto de tareas:

• Gestión de dispositivos
• Gestión de procesos
• Gestión de memoria

Todo lo que vamos a ver en este artículo ya lo hemos visto, aquí simplemente vamos a pegarlo todo para formar un sistema operativo. No todos los sistemas operativos contienen todos estos componentes, o incluso aunque los tengan pueden ser más o menos sofisticados, así que tendremos que contar cosas más o menos generales.

Separación de privilegios

Ya vimos anteriormente que los procesadores modernos tienen dos modos de funcionamiento distintos: uno normal y otro privilegiado. El sistema operativo se ejecuta sobre todo en modo privilegiado, mientras que las aplicaciones se ejecutan siempre en modo normal: cuando necesitan hacer algo privilegiado no lo hacen directamente, sino que se lo piden al sistema operativo, que lo hará, o no lo hará, o lo hará, pero más tarde, o lo que corresponda, dependiendo de muchas cosas que ya veremos (y de muchas otras que no veremos).

Aunque este concepto ya lo hemos visto antes, vamos a volver a contar lo más importante aquí para que lo puedas contextualizar con el resto del artículo.

Las instrucciones privilegiadas más importantes son:

• Configuración de las interrupciones
• Configuración de la pila
• Configuración de los elementos hardware que controlan el resto de componentes
• Operaciones de entrada y salida hacia y desde los periféricos

Las instrucciones normales más importantes son:

• Operaciones aritméticas y lógicas
• Traer y llevar datos a y desde la memoria principal… pero solo de la memoria que sea mía (ya veremos eso)
• Poner y quitar datos en la pila… pero no configurarla (eso lo vimos antes)
• Saltos y subrutinas… pero no a zonas de la memoria que no son mías (otra vez)
• Interrupción software o petición al sistema; por si no la recuerdas, esta instrucción era como una interrupción más, que saltaba a una posición conocida (en la cual quien estaba era el sistema operativo)

Funcionamiento basado en interrupciones

Este concepto también lo hemos visto antes, pero vamos a enfatizarlo aquí: en un sistema operativo moderno, todo ocurre porque ha llegado una interrupción (salvo la inicialización, claro).

Cuando el ordenador arranca (más adelante veremos todo el proceso de arranque), a quien está ejecutando es al sistema operativo, que durante su inicialización configura la pila, configura todos los dispositivos que tiene y, lo más importante desde este punto de vista, configura el vector de interrupciones. El vector de interrupciones contiene la dirección de memoria que debe ejecutarse cuando ocurra cada interrupción. La gracia es que quien está en esas posiciones de memoria es siempre el sistema operativo, de modo que será siempre siempre el sistema operativo quien atienda cualquier interrupción.

Podemos dividir las interrupciones en los siguientes grupos:

• La interrupciones generadas por los dispositivos: siempre que un dispositivo (por ejemplo un teclado, un disco duro, una tarjeta de sonido…) quiere decirle algo a la CPU, levanta una interrupción, y ahí está el sistema operativo para procesarla.
• Una particular de las anteriores: un reloj. Los ordenadores tienen un reloj que genera interrupciones cada cierto tiempo (como ejemplo, digamos que cada 1ms)… cada vez que el reloj genera una interrupción, ahí está el sistema operativo para hacer algo.^[1]
• La interrupción software: siempre que una aplicación de usuario necesita pedirle alguna cosa al sistema operativo, lanza una interrupción software, y ahí está el sistema operativo para procesar la petición.
• Las interrupciones debidas a error: cuando ocurre un error, los propios componentes del ordenador generan una interrupción… y ahí está el sistema operativo para hacer algo al respecto, si puede.

Gestión de procesos

Las gestión de procesos, como su propio nombre indica, se encarga de gestionar procesos. ¿Y qué es un proceso? Pues… un proceso es la unidad mínima que gestiona el componente de gestión de procesos. Está bien, eso es una definición tautológica, así que que, para la profundidad que vamos a darle a este texto, vamos a decir que un proceso es un programa: el navegador, el lector de correo, tu procesador de textos… pero también muchos otros procesos que el ordenador necesita para funcionar y que probablemente ni siquiera sabes que existen.

Parte del árbol de procesos en un Windows 7, obtenido con Process Explorer

Por lo tanto, tal y como hemos visto, la función más importante de la gestión de procesos es ir asignando la CPU a los procesos cada vez que les toca. El sistema de gestión de procesos tiene una lista con todos los procesos del sistema y su estado. Cuando un proceso esté realizando una operación de entrada/salida (que ya hemos visto que tardan mucho), el sistema de gestión de procesos lo saca de la CPU, busca uno que esté listo para ejecutar y lo pone en la CPU. También realiza esa operación periódicamente, usando el reloj que describíamos más arriba: cada 1ms (por ejemplo) saca de la CPU al proceso que esté y pone al siguiente en la lista (habitualmente esto se puede combinar con algún tipo de gestión de prioridad, por ejemplo como se puede ver en Windows 7 en la siguiente figura).

Asignación de prioridad de un proceso, en Process Explorer

¿Y qué significa eso de “sacar al proceso de la CPU” o “poner al proceso en la CPU”? Eso es lo que se llama un cambio de contexto. Cuando sacamos un proceso de la CPU, queremos que, cuando luego lo volvamos a meter, continúe por donde iba, exactamente con el mismo estado, como si nada hubiera pasado entre medias. Lo que haya que guardar exactamente depende del procesador y del sistema operativo, pero lo habitual es que haya que guardar el contador de programa PC, el puntero de la pila SP y todos los registros que tenga la CPU (a menudo hay que guardar alguna cosa más, pero son cosas que no hemos visto). Los tomamos con mucho cuidado y los guardamos en la descripción de nuestro proceso. Luego, cuando queramos volver a poner ese proceso en la CPU, simplemente volvemos a copiar esos datos desde la descripción del proceso a la CPU y seguimos ejecutando por donde dijera el PC: desde el punto de vista del proceso que se estaba ejecutando, no ha cambiado nada, para él todo sigue como estaba.

Así, un proceso es una cosa abstracta, un hilo de ejecución, un programa, que vamos “poniendo en la CPU” de vez en cuando.

Gestión de memoria

Cuando diseñamos nuestro ordenador, la memoria simplemente estaba ahí, lista para ser usada por la CPU. Pero ahora queremos que distintos procesos accedan a distintas partes de la memoria, pero no a otras. Más aún: aunque no lo hemos visto, en general queremos que cada proceso vea toda la memoria como si fuera toooooda para él, como si él fuera el único proceso ejecutándose en la máquina.

Para ello necesitamos introducir un nuevo componente hardware, situándolo entre la CPU y la memoria principal. Vamos a llamar a este componente MMU (Memory Management Unit, unidad de gestión de memoria); todas las CPUs modernas tienen una MMU.

Cuando la MMU se ve desde la CPU, se comporta como si fuera directamente la memoria principal MP. Es decir, la CPU le pide la posición 0xA1B2C3D4 y le da su contenido; le pide guardar algo en la posición 0xE5F6A7B8 y lo guarda. ¿Cómo lo hace? Mandándolas a la MP, obviamente, no puede hacerlo de otro modo.

La gracia está en que el mapeo en la posición que me pide la CPU y la posición correspondiente en la MP es configurable. Así, yo puedo configurar la MMU para decirle: siempre que te pidan las posiciones desde la 0×00000000 a la 0x0000FFFF, utiliza en realidad las que van desde 0xA0000000 a 0xA000FFFF. Y así para todas las posiciones de memoria posibles. El truco está en que el módulo de gestión de memoria decide hacer mapeos distintos para procesos distintos, de modo que cada vez que el sistema de gestión de procesos mete un proceso en la CPU, también cambia la configuración de la MMU para que el proceso en cuestión crea que tiene toda la memoria disponible, pero en realidad solo pueda acceder a las posiciones que tiene asignadas. Eso quiere decir que los procesos ya no pueden simplemente acceder a la memoria, sino que antes de hacerlo deben pedírsela al sistema operativo, y tienen que “liberarla” cuando hayan terminado de usarla.

Estado de la memoria en un Windows 7

Gestión de dispositivos

Hemos visto que una de las funciones más importantes del sistema operativo es abstraer el uso de los dispositivos: nosotros usamos de la misma manera un teclado Logitech y uno de Trust, una pantalla de HP y una de LG, un disco duro Seagate y uno de Western Digital, una tarjeta gráfica de MSI y una de AMD…

Así que el sistema operativo agrupa los dispositivos por categorías y define una forma estándar de usarlo. Y luego cada fabricante de dispositivos proporciona una piececita de software para traducir esa forma estándar a lo que su dispositivo específico necesita. Esa piececita es lo que se llama un driver de dispositivo.

Vista parcial de dispositivos en un PC con Windows 7

Además, el sistema operativo se encarga de que los dispositivos se utilicen de forma ordenada.

Vamos a ver el ejemplo de una tarjeta de sonido, que tiene tanto entrada (el conector del micrófono) como salida (la salida de línea que conectamos a los altavoces). Cuando un proceso en cuestión necesita reproducir sonido no se pone directamente a enviarle datos a la tarjeta de sonido (recuerda que, como hemos visto, probablemente enviar sonido a la tarjeta sea algo tan “sencillo” como escribir una cierta información en unas determinadas posiciones de memoria). Si lo intentara, no podría, porque la MMU o la propia separación de privilegios de la CPU se lo impedirían. En lugar de eso, cuando necesita enviar sonido a la tarjeta, deja los sonidos (debidamente codificados) en la pila y genera una interrupción software.

Sabemos que quien atenderá esa interrupción será siempre el sistema operativo, en concreto su módulo de gestión de dispositivos, que tomará los sonidos que hay en la pila, y se los dará al driver de la tarjeta de sonido, que, ahora sí, los enviará a la tarjeta de sonido, que los reproducirá.

En el sentido contrario es parecido. Cuando un proceso necesita recibir sonido del micrófono (por ejemplo, porque sea un programa de videoconferencia) utiliza la interrupción software para decirle al sistema operativo “eh, a partir de ahora quiero recibir el sonido del micrófono; cuando tengas algo dáselo a esta subrutina mía”. Y el sistema operativo se lo apuntará en una tabla. Cuando ahora llegue sonido a través del micrófono, ¿qué hará la tarjeta? Generará una interrupción, que atenderá el sistema operativo (en realidad, quizá lo haga el driver del fabricante, pero eso es parte del sistema operativo); el sistema recibirá el sonido de la tarjeta y se lo dará a la subrutina en cuestión del proceso en cuestión.

Sistema de ficheros

Existe un componente más que, por su importancia, suele nombrarse aparte: el sistema de ficheros. Todos lo hemos usado alguna vez, así que seguro que lo entiendes rápido.

Vista parcial de un sistema de ficheros en Windows 7

En los discos duros no se lee y escribe directamente, ni siquiera a través del driver correspondiente, sino que el sistema operativo ofrece un nivel de abstracción más: los ficheros. El sistema operativo ofrece el concepto de fichero como una sucesión de bytes, y el de directorio (o carpeta, en terminología Microsoft) para organizar ficheros, y luego ofrece formas de acceder a ellos, de listar su contenido, de abrirlo y cerrarlo…

No podemos entrar en mucha profundidad, porque cada sistema de ficheros es distinto y contar los detalles llevaría un libro completo. Así que vamos a ver por encima cómo funciona uno de los sistemas de ficheros más extendidos: FAT (existen otros, mucho más sofisticados y potentes, pero también mucho más difíciles de entender). Probablemente uses el sistema de ficheros de tipo FAT en un montón de sitios, sobre todo en tarjetas de memoria o pendrives USB.

Para empezar a explicarlo hay que entender que los discos no se leen byte a byte, sino bloque a bloque (de hecho, se les llama genéricamente así, dispositivo de bloque, tanto si son un disco magnético clásico como un pendrive, un CDROM o cualquier cosa que pueda parecer un disco). El tamaño de dichos bloques depende de la tecnología y el fabricante, pero supongamos que se leen en bloques de 1kB (1024 bytes) y que nuestro disco es pequeñito, de solo 16kB.

Lo que tenemos son 16 bloques de 1kB cada uno. El primero de ellos es un poco especial, porque lo que contiene es la tabla de asignación de ficheros (en inglés, File Asignation Table… FAT… de ahí el nombre). Y ahora supongamos que tenemos un fichero llamado “leeme.txt” que en su descripción dice que su primer bloque es el 2. Así que sabemos que está en el bloque 2 y quizá en alguno más. Nos vamos a la tabla de asignación del ficheros del primer bloque y vemos que en la posición 2 hay un 11… eso quiere decir que continúa en el 11. Ya tenemos el 2 y el 11. Miramos en la posición 11 y vemos un 8, así que continúa en el 8. Seguimos buscando así y tenemos el 7 y un -1. El -1 indica que se ha terminado, así que ya sabemos que el fichero “leeme.txt” está en los bloques 2, 11, 8 y 7. Así que cuando queramos leer ese fichero, esos son los bloques que debemos pedirle al disco duro.

De esta forma tan tonta funciona el sistema de ficheros FAT, y por eso se usa tanto en aparatos sencillos: porque es muy fácil de implementar.

¿Y en realidad?

Pues en realidad es un poco más complejo. Los sistemas de ficheros son mucho más sofisticados, y de hecho puedes tener más de uno a la vez; los drivers de dispositivos pueden ser millones, y en realidad hay dispositivos que ni siquiera funcionan exactamente así (como pueden ser las impresoras); no todas las tareas del sistema operativo se hacen durante las interrupciones; gestionar memoria y procesos es mucho más complicado de lo que hemos visto aquí; en fin… esto es una introducción. Lo que aquí hemos contado en un solo artículo puede representar un libro completo o un curso completo en cualquier carrera universitaria del ramo… pero lo fundamental lo tienes ahí. Cuando demos referencias al final podrás profundizar más, si lo deseas.

En el próximo capítulo veremos cómo arrancar el ordenador.

1. No confundir este reloj con el reloj del procesador, que va a 1GHz o algo de ese orden de magnitud. Este es un reloj específico para generar estas interrupciones.

En el último capítulo de esta serie vimos las diferencias entre los ordenadores reales y los sistemas supersimplificados que hemos contado aquí para aprender, y vimos que muchas de esas diferencias solo se entendían como apoyo en su relación con el sistema operativo.

Pero, ¿qué es el sistema operativo? En el último capítulo esperábamos que tuvieras una idea más o menos intuitiva de lo que era un sistema operativo simplemente viendo los ejemplos de nuestra vida cotidiana: Windows, en todas su variantes, es un sistema operativo. Linux también lo es. Mac OS. Android, iOS,… en fin, esos son los ejemplos que a todos nos vienen a la mente rápidamente. En sistemas más grandes tenemos UNIX en todas sus variantes, así como los sistemas operativos de los mainframes de IBM y similares: z/OS (el antiguo MVS), DOS/VSE…

Así que ya tenemos claro lo que es un sistema operativo… ¿o no?

Pues no, no tanto. Y es que la discusión no es baladí, incluso con implicaciones legales y denuncias por abuso de monopolio de por medio.

Existen muchas definiciones sobre lo que es el sistema operativo, casi tantas como libros que existen sobre el tema, pero nosotros vamos a intentar una más: el sistema operativo es la parte del software que se encarga de gestionar los recursos del ordenador a petición de las aplicaciones.

Supongo que te has quedado como estabas. O peor aún, porque antes lo tenías más o menos claro, y ahora quizá ya no tanto.

Así que vamos a intentar una aproximación histórica, a ver si poco a poco vamos centrando la definición. Para ello vamos a ver cómo eran y cómo se usaban los ordenadores inicialmente, y cómo el sistema operativo surgió casi por necesidad, más que por diseño.

Empezamos la batallita a mediados del siglo XX, justo después de que von Neumann diseñara su arquitectura. El que quería usar el ordenador se escribía su programa, iba allí, lo ejecutaba y listo. Al fin y al cabo, solamente unos pocos privilegiados tenían acceso a dicha máquina,^[1] y menos aún sabían cómo hacer programas para ella, así que todo lo más había una pizarra donde se apuntaban para decir “eh, de 8 a 12 necesito usar el ordenador para calcular unos logaritmos” (salvo que lo necesitara el jefe entre medias, me imagino).

Supongo que rápidamente aparecerían las primeras bibliotecas de programas. No solo para operaciones matemáticas, sino también (y esta es la parte que nos interesa) para acceder a los dispositivos de entrada-salida: leer del teclado, escribir en la impresora (porque no, no había pantallas todavía), leer y escribir en las cintas magnéticas…  Si recuerdas cómo se escribía en nuestra rudimentaria pantalla, ¿imaginas lo complicado que debe ser escribir en una cinta magnética o en un teletipo? Una vez que has escrito la biblioteca de programas que lo hace, y encima funciona, no quieres volver a escribirla nunca más; ni siquiera a tus enemigos se lo deseas. Así que supongo que los afortunados que vivieron aquello probablemente compartirían esas bibliotecas: alguien creaba la biblioteca, la hacía sencilla de usar (dejando en el interior toda la complejidad de manejar los dispositivos de entrada-salida) y la dejaba a disposición de los demás.^[2] Es decir estas bibliotecas nacieron como una forma de abstraer el uso del hardware. Fíjate en que hasta aquí no “gestiona” dicho hardware, solo simplifica su uso.

También en esta época se empezaron a usar en los ordenadores las tarjetas perforadas,^[3] de modo que el científico-programador almacenaba cómodamente las tarjetas una vez perforadas en su despacho, y así cuando fuera a usar el ordenador perdería poco tiempo cargando el programa. ¡Hemos avanzado una barbaridad! Empezamos los años 50.

Tarjetas perforadas (Marcin Wichary, cc-by-2.0, http://www.fotopedia.com/items/flickr-2210753092)

Pero, con el tiempo, cada vez más gente quería usar el ordenador, y cuando llegaban a usarlo no siempre estaba libre, así que tenían que esperar. De modo que entrenaron a un señor cuya misión era cargar el siguiente programa que estaba en la lista de espera en cuanto el que estaba ejecutándose hubiera terminado, y recoger la salida que hubiera generado para llevársela a quien había encargado el trabajo (job es como se llamaban esa tareas, trabajo, en inglés). Así que los científicos que querían usar el ordenador escribían su programa (o mejor dicho, lo perforaban en las tarjetas perforadas) y se lo daban al operario para que lo cargara, a la espera de que hubiera hueco libre para ejecutarlo. Por cierto que en esta época es cuando se inventaron los lenguajes de programación y los compiladores (FORTRAN, inicialmente). Estamos a finales de los 50. Pero, claro, rápidamente se pensó que se podía prescindir de ese ser humano cargador (loader, en inglés), y que los programas podían quedarse en el propio sistema, listos para ser ejecutados, pero a la espera de que terminara el que estuviera antes que ellos en la cola. Como la cola de una frutería, vamos. A esto se le llamó sistemas batch (batch es “lote” en inglés).

¿Y quién iba a encargarse de ir dando entrada a los programas según quedara hueco libre? Hubo que escribir algún “programa” un poco especial, que estuviera siempre cargado en la máquina, y que fuera ejecutándose cuando un programa “de usuario” terminase, pasando a ejecutar al siguiente en la cola. Había nacido el sistema operativo.

Pero también rápidamente se dieron cuenta de que ocurría un efecto curioso: cuando el programa tenía que hacer operaciones puramente de cálculo, estaba ahí, a todo trapo, ejecutando instrucciones sin parar. Pero cuando necesitaba interactuar con los dispositivos de entrada-salida (leer o escribir algún dato) se quedaba parado por largos periodos de tiempo mientras el dispositivo de entrada-salida hacía lo que le habían pedido hacer. No estamos refiriéndonos a nuestro ejemplo del teclado, en el que esperamos a que el usuario pulse una tecla. Ni que decir tiene que estos primeros programas no eran en absoluto interactivos, así que ni se pensaba en que el usuario pulsara alguna tecla mientras se ejecutaba el programa. A lo que me refiero es a la comunicación con otras máquinas. Piensa por ejemplo en una impresora a la que le das orden de hacer un salto de línea: la impresora tiene que encender un motor, girarlo unos cuantos grados (para mover el cilindro que arrastra el papel hasta la siguiente línea), luego moverlo hacia la derecha para que se posicione en la primera columna… ¿cuánto tarda en hacer eso? Que tarde del orden de un segundo, o incluso más, dependiendo del tipo de periférico que sea, no es descabellado.

Hasta para aquellos primitivos ordenadores, eso era muchísimo tiempo. Para que te hagas una idea, el IBM 360 original (de 1964) ejecutaba 34000 instrucciones por segundo; un ordenador de sobremesa puntero actual sobrepasa ampliamente los 10.000.000.000 de instrucciones por segundo, así que imagina lo que le da tiempo a hacer en 1ms… una barbaridad.

Inauguración del primer IBM 360 instalado en Francia, en 1967 (Nicolas Roussel, cc-by-3.0, http://www.fotopedia.com/items/d66945df-37cc-4ce2-aa76-eb2ce9809ae7)

En paralelo se dio otro efecto, esta vez de negocio: los ordenadores ya no eran un juguete de los científicos, que hacían millones de operaciones matemáticas para calcular el trigésimo decimal de PI, sino equipos que usaban las grandes agencias gubernamentales, los grandes bancos, las grandes universidades… para su negocio. Por un lado, esa gente hacía muchas más operaciones de entrada-salida que los científicos, ya que sus ordenadores se solían usar para procesar grandes volúmenes de datos (que a menudo estaban en cintas magnéticas) en lugar de para realizar muchos cálculos matemáticos. Y, por otro, ya había que empezar a tener en cuenta el presupuesto… y el precio de ese ordenador tenía tantos ceros y había tanta gente a la cola esperando para usarlo que el coste de esas pausas, desperdiciadas simplemente esperando a que se rebobinara la cinta, empezaba a no ser despreciable.

Así que se les ocurrió lo siguiente: si tenemos programas en la cola, esperando para ser ejecutados, ¿por qué no vamos empezando con ellos en las pausas del programa que se está ejecutando? Con esto (principios de los setenta) nacieron los sistemas multiprogramados: más de un trabajo podía estar “medioejecutándose” a la vez. Obviamente, ejecutándose-ejecutándose de verdad, solo había uno, pero en cuando ese se quedaba esperando a alguna operación de entrada-salida, otro ocupaba inmediatamente su lugar en la CPU, para ir avanzando. Con esto nació la gestión de procesos tal y como la conocemos hoy (ya existía cierta gestión de procesos en la decisión de cargar un trabajo cuando el otro acababa, pero era poco más que gestionar una cola, como el Turn-O-Matic de la charcutería).

Pero claro, ahora ya teníamos varios programas a la vez en el ordenador. Imagina que a uno de ellos le da por escribir en una posición de memoria que es de otro programa. Ni siquiera estoy pensando en temas de seguridad o privacidad de los datos del otro programa, sino en simples errores. A lo mejor el “otro programa” era el cálculo de los impuestos del Departamento del Tesoro (el equivalente al Ministerio de Hacienda en España) y modificar por error un número allí podía tener consecuencias catastróficas (para alguien). Así que había que aislar unos programas de otros: la memoria de unos no podía ser vista por otros. Así que los programas se vieron forzados a pedirle por favor al sistema operativo que les diera memoria, a liberarla cuando terminasen, a no salirse de ella y cosas así. Había nacido la gestión de memoria.

Lo mismo ocurría respecto a la entrada/salida: ahora ya podía haber más de un programa que intentara por ejemplo imprimir, y, si se permitía, al final saldría todo embarullado por la impresora. Así que no se puede permitir que los programas impriman directamente, sino que deben pedirle al sistema operativo que imprima, y él ya lo hará cuando considere que no interfiere con los demás programas (y lo mismo, por supuesto, aplica al resto de dispositivos de entrada y salida: la pantalla, leer/escribir en cinta, en disco…). Es decir, el sistema operativo tuvo que empezar a gestionar el hardware.

Pero todo era aún muy rudimentario (desde nuestro punto de vista, claro). Macluskey cuenta siempre que el Sistema Operativo del ordenador en que comenzó a trabajar a mediados de los setenta sólo ocupaba 3 Kb en la memoria de la máquina. 3Kb: 3.000 octetos, así que imaginaros lo poquito que podía hacer con tan poco código. Los trabajos no eran nada interactivos: una vez empezaban, seguían hasta que acababan o hasta que daban un error… lo cual no era infrecuente. Si has programado alguna vez un simple “ahorcado”, ¿te puedes imaginar lo que puede ser programar eso en  FORTRAN o, peor aún, en ensamblador? La probabilidad de cometer un error era más bien una certeza. Pero el problema es que, aun con los sistemas multiprogramados, desde que tú enviabas el programa al ordenador hasta que volvía el resultado de su ejecución podían pasar horas o incluso días. Y todo para descubrir a lo peor que tenías un error de sintaxis en la cuarta línea del programa y que la espera no había servido de nada.^[4][5]

Así que se buscó que los programadores pudieran utilizar el ordenador aún cuando ya hubiera un programa ejecutándose. La solución es muy sencilla: en los sistemas multiprogramados metíamos un programa de los de la cola cuando el principal hacía operaciones de entrada-salida… ¿por qué no hacemos ese cambio de forma obligada cada cierto tiempo? Mejor aún: si tengo 6 programas cargados, puedo darle la CPU primero al 1, luego al 2, luego al 3… así hasta el 6… y luego otra vez al 1, y al 2… y así continuamente. ¿No? Si hago eso, y lo hago lo bastante rápido (por ejemplo, cada 10ms) a todos los programas casi les parece que están continuamente ejecutándose, aunque en realidad vayan a saltos. Grosso modo ocurre que si hay 8 programas ejecutándose a ratitos en un ordenador de potencia 100 (signifique eso lo que signifique), casi casi le parece a cada uno de ellos que en realidad se está ejecutando él solo en un ordenador de potencia 12,5 (12,5=100/8). Habían nacido los sistema de tiempo compartido.^[6]

Ordenador Cray2, que en 1985 era el ordenador más potente del mundo… y permaneció el primero hasta 1990 (Matthew Phillips, cc-by-nd-2.0, http://ja.fotopedia.com/items/flickr-2456335311 ; expuesto en el Musée des arts et metiers de París)

Las posibilidades de esta aproximación fueron ingentes. No solo para los programadores, que ahora podían probar sus programas rápidamente, sino porque permitía hacer programas que utilizaran usuarios sin formación técnica. Era posible hacer programas interactivos: el programa podía pedirle al usuario que hiciera algo y actuar en consecuencia. Simplemente, mientras el programa estaba esperando a que el usuario tecleara sus datos nunca le tocaba la CPU y listo. El sistema operativo se encargaba de ello. Y cuando tenía trabajo que hacer, le iba tocando la CPU a ráfagas cortas y rápidas. Se desplegaron terminales, de forma que más de un usuario pudiera usar el ordenador a la vez, y se les pusieron los terminales en el despacho. Ahora ya era posible hacer editores de texto, hojas de cálculo, bases de datos interactivas,… ¡incluso juegos! Había nacido la informática moderna.

El resto… ya casi ni es historia. Los sistemas se miniaturizaron, se hicieron más baratos, su consumo energético se redujo, se inventaron los interfaces visuales, las redes… de forma que hoy en día llevas más potencia en tu teléfono móvil que aquellos primitivos ordenadores de von Neumann (pero no un poquito, no, sino muchos órdenes de magnitud más). Si eres un lector habitual de este blog, conoces la serie de Macluskey sobre la historia de la informática. Y si no la conoces, ¿a qué estás esperando, alma de cántaro? Te estás perdiendo una de las mejores series que se ha escrito en El Cedazo.

En el próximo capítulo profundizaremos un poco más (solo un poco) en el funcionamiento del sistema operativo.

1. El UNIVAC 1, el primer ordenador con arquitectura Von Neumann.
2. Digo “supongo” con toda la intención, porque no recuerdo haberlo leído en ningún sitio. Pero vaya, no parece una suposición descabellada.
3. Existían desde hacía mucho tiempo para definir el patrón que debían usar los telares.
4. Yo me desespero cuando hoy en día una prueba tarda más de unos cuantos segundos, así que me imagino lo que debía ser esperar hasta el día siguiente.
5. Nota de Macluskey: Cuando no habías conocido otra cosa, no lo echabas de menos: así era como se funcionaba, y punto. Usabas los tiempos muertos en escribir tu o tus siguientes programas… en realidad también nosotros, los programadores de la época, éramos multiprogramadores.
6. De hecho, debido al tiempo perdido en la entrada-salida, estadísticamente a los programas les parece que es incluso mejor que 12,5.

Hemos dedicado los últimos capítulos de esta serie a ver unos ordenadores muy sencillitos, pero que capturaban la esencia de los ordenadores modernos. Como te imaginarás, los ordenadores reales son bastante más complejos, así que vamos a dedicar unas palabras a dar algunas pinceladas sobre las diferencias.

A diferencia de los capítulos anteriores, este será de mucho blah-blah-blah, mucha batallita. No creas, no obstante, que se trata de un capítulo trivial: algunas de las cosas que veremos serán importantes para los siguientes capítulos. De hecho, algunas de las cosas que veremos solo las nombraremos someramente, porque su importancia solo quedará patente cuando veamos los sistemas operativos más adelante. Eso quiere decir que si alguno de los párrafos te resulta un poco… inútil… como si no supieras muy bien por qué eso es importante… no te preocupes mucho, que profundizaremos en ello en el futuro.

Diagrama del microcontrolador 8051 de Atmel (http://www.atmel.com/Images/doc4316.pdf)

En el dibujo de cabecera puedes ver el diagrama del 8051 de Atmel. Los 8051 (y sus variantes) son unos de los microcontroladores más utilizados en sistemas empotrados, en pequeños proyectos amateur y de investigación, porque es baratísimo (alrededor de 1€) y tiene una comunidad de usuarios muy grande detrás.^[1]

El 8051 fue un microcontrolador diseñado por Intel en 1980. Es decir, que no es lo más de lo más en tecnología punta, pero ya es significativamente más complejo que los sistemas C16A, C16B y C16C que hemos visto nosotros. Así que no te digo nada si lo que intentáramos fuera estudiar un ordenador moderno, como los Intel Core i7…

¿Podemos ver algunas diferencias? Algunas ya las hemos ido viendo cuando veíamos la memoria o las interrupciones. Otras son solamente diferencias cuantitativas, como el tamaño de los buses y los registros; esas vamos a obviarlas, porque no suponen un cambio de concepto, simplemente tiene un tamaño distinto. Vamos a ver las diferencias que sí sean importantes.

Para empezar, es muy habitual que hoy en día ya no hablemos de un ordenador como un bloque monolítico, sino que se suelen comprar los componentes por separado: por un lado la CPU, por otro lado la memoria, por otro lado los dispositivos de entrada/salida… pero bueno, supongo que eso ya lo sabías, a estas alturas del siglo. Así que vamos a centrarnos en las diferencias más arquitecturales.

Las ALUs reales tienen muchísimas más operaciones que las que hemos visto aquí y las CPUs reales tienen también muchísimas más instrucciones.^[2] Nosotros hemos tenido que hacer una subrutina para hacer la operación “multiplicar”, pero no te sorprenderá que eso sea una instrucción que venga de serie en cualquier CPU que se precie. Por ejemplo, el 8051 de más arriba tiene en torno a un centenar de instrucciones, y ya estamos hablando de una CPU antigua. Las CPUs más modernas que esa tienen operaciones para coma flotante, operaciones multimedia, gestión de otros componentes de la CPU… Nosotros hemos visto cómo hacer la multiplicación era una operación muy habitual, y hacerla a base de una subrutina que haga operaciones más simples es un incordio, de modo que parece que proporcionar instrucciones que hagan operaciones más complejas parece buena idea. Bien, pues sí lo es. Y cuantas más, mejor.

¿No?

Pues no está tan claro. Aquí hay dos corrientes distintas, y cada una tiene sus ventajas. Por un lado tenemos la corriente CISC (Complex Instruction Set Computer, computador con juego de instrucciones complejo) y por otro tenemos RISC (Reduced Instruction Set Computer, computador con juego de instrucciones reducido). La corriente CISC, de la cual los procesadores Intel que usamos en nuestros ordenadores son probablemente el mayor exponente, pretende que la mayor cantidad posible de instrucciones se hagan en el nivel más bajo posible, de modo que puedan optimizarse y hacerse muy rápidas, mucho más rápidas que hacer subrutinas que hagan lo equivalente. Por ejemplo, nuestro editor Macluskey recuerda que uno de los ordenadores con los que él ha trabajado tenía una instrucción ensamblador que hacía la ordenación (SORT).^[3]

La corriente RISC, de la cual el mayor exponente ahora mismo serían los procesadores ARM que llevan casi todos los teléfonos móviles actuales, propugna en cambio que las instrucciones que ofrezca la CPU sean muy muy sencillas, pero muy muy eficientes. Puede parecer que los diseñadores de sistemas CISC no van a ser imbéciles y a hacer las instrucciones menos eficientes que los que diseñan RISC… pero no es eso lo que quiere decir. Lo que ocurre es que al reducir no solo la cantidad de instrucciones, sino también su tipo, se pueden aplicar optimizaciones que serían imposibles en CISC. Por ejemplo, en tecnología RISC se intentan evitar las instrucciones que operan con la memoria: solo las instrucciones que cargan y guardan cosas en memoria deben acceder a memoria; el resto de operaciones deben operar exclusivamente sobre los registros de la CPU (el equivalente a nuestro acumulador). El caso es que, efectivamente, con esas restricciones parece que es más fácil hacer las instrucciones sencillas más eficientemente.^[4] Al final ocurre que los procesadores RISC modernos tienen más instrucciones que los CISC antiguos, de modo que la R de Reduced hay que entenderla con cuidado: no es tanto que tenga pocas instrucciones como que dichas instrucciones sean muy sencillas.

Es esta una pelea que no está resuelta, y que además probablemente no se resolverá a medio plazo, pues obviamente cada una tiene sus aplicaciones.

Otra diferencia importante entre los ordenadores reales y nuestro C16C es la memoria. Nosotros hemos proporcionado una memoria principal y una memoria interna con la que trabajar (el acumulador). Pero las CPUs reales tienen:

• Muchos más registros internos. Parecidos a nuestro acumulador, pero muchos más.
• La lectura y escritura en la memoria no suelen tardar un tick de reloj, sino muchos más.
• Para paliarlo, se suele introducir uno o más niveles de memoria intermedios entre la CPU y la memoria RAM, a los que se suele llamar memoria caché. Esta memoria caché es mucho más rápida que la memoria principal… y más cara, claro, y por eso suele ser muuucho más pequeña. Para lo que sirve es para almacenar temporalmente en ella las posiciones de memoria a las que se está accediendo muy a menudo, para que esos accesos sean más rápidos. Desde el punto de vista del programa, esta memoria caché suele ser transparente, en el sentido de que no se accede a ella directamente, sino como si fuera parte de la memoria principal. Si da la casualidad de que lo que buscamos está en esta caché, será muy rápida… pero desde el punto de vista del programa no hay diferencia.

La tercera diferencia importante está en el acceso a los dispositivos de entrada/salida. En nuestro C16C los dispositivos de entrada/salida estaban directamente conectados al bus de memoria. Es decir, escribir en la pantalla era exactamente igual que escribir en la memoria. Pero en algunos sistemas (en particular en los procesadores Intel que casi todos tenemos en casa) existen dos buses A (y consecuentemente dos buses D): uno para la memoria principal y otro para la entrada/salida. Es decir, simplificándolo, tendría una arquitectura como la siguiente:

Fíjate en que ahora tenemos un bus DM/AM (la M es de Memory, memoria) y otro bus DIO/AIO (IO es de Input-Output, entrada-salida). Lógicamente, donde antes había instrucciones ST y LD, ahora tiene que haber STM, STIO, LDM y LDIO. Ah, y un detalle más: si decíamos que el acceso a memoria no ocupaba un tick de reloj, sino muchos, el acceso a dispositivos de I/O ocupa muchísimos más. Si esos dispositivos de entrada salida implican movimientos físicos (como por ejemplo rebobinar una cinta magnética o mover el cabezal de un disco duro), el tiempo puede ser varios órdenes de magnitud mayor que un tick de reloj (esto tendrá implicaciones más adelante, cuando veamos cómo lo abordan los sistemas operativos).

La forma en que se accede a memoria es una cuarta diferencia, que no hemos visto hasta ahora. Como no afecta a cómo funciona el computador, solo vamos a nombrarlas por completitud (es decir, que si no entiendes muy bien lo que significan, no te obsesiones, que no es importante para seguir). Hasta ahora, cuando en nuestras instrucciones poníamos <addr>, significaba que allí estaba el dato con el que queríamos operar. Fácil. Es lo que se llama direccionamiento directo. Pero existen más formas de direccionamiento:

• Direccionamiento indirecto: la dirección a la que hace referencia el parámetro de la instrucción no contiene el valor con el que operar, sino la dirección en donde está el verdadero valor con el que operar. Si has programado en C (o en algún otro lenguaje de bajo nivel) esto es simplemente un puntero.
• Direccionamiento indexado: la dirección efectiva en donde está el valor con el que operar se obtiene sumando la posición base más un índice. Es decir, es una forma de recorrer arrays.
• Direccionamiento relativo: la dirección efectiva del operando se obtiene sumando la dirección en donde está la instrucción más el parámetro proporcionado (que podría ser negativo). Este mecanismo se puede usar para hacer código que se pueda mover de una posición de memoria a otra sin que deje de funcionar.

Existe una última diferencia importante respecto al tratamiento de la memoria: la MMU (Memory Management Unit, unidad de gestión de memoria). Pero esa no la veremos hasta que no lleguemos a la parte de gestión de memoria de los sistemas operativos, porque si intento explicarla ahora solo va a confundirte.

La última diferencia importante se refiere al modo de ejecución. Supongo que estás acostumbrado a que tu ordenador tenga cierta separación de privilegios. Probablemente conoces lo que es el usuario Administrador (en Windows) o root (en Unix), y sabes que puede haber más usuarios. Y sabes que (a menos que haya un bug) un usuario no puede acceder a las cosas de otro. ¿Cómo puede hacer eso el ordenador? Con lo que hemos visto hasta ahora, una vez que se está ejecutando un programa, parece que tiene acceso a todo, que puede ejecutar todas las instrucciones… en particular, podría ejecutar instrucciones que accedan a los datos de otro usuario. ¿No? Pues no. La mayor parte de los sistemas modernos tienen algún mecanismo de separación de privilegios, de modo que, cuando la CPU está en modo normal, hay muchas instrucciones que no puede ejecutar. Si el programa que está ejecutando contiene esas instrucciones, dará un fallo o simplemente las ignorará. Y si está en modo privilegiado, entonces sí, puede ejecutarlas todas.

• Ejemplos de instrucciones “privilegiadas”: gestión de la memoria, de acceso a los dispositivos de entrada-salida, de configuración de la pila, de configuración de las interrupciones… Una muy importante es precisamente “salir del modo privilegiado”.
• Ejemplos de instrucciones “normales”: operaciones aritméticas, operaciones lógicas, lectura y escritura de memoria (pero solo de determinadas zonas de memoria), saltos, subrutinas… y poco más. Ah, sí, hay una muy importante: la interrupción software.

Vamos a presentar la interrupción software muy someramente, porque este es el lugar que corresponde, pero más adelante lo veremos en detalle. La interrupción software es como una interrupción de las que hemos visto antes, con la única diferencia de que no se dispara por un evento del hardware, sino porque se ejecuta la instrucción SWIRQ (por ponerle un nombre). Una vez que salte esa interrupción, se interrumpirá la ejecución de lo que esté haciendo, como siempre que hay una interrupción, y saltará a una posición de memoria conocida y pasará al modo privilegiado. La gracia es que quien reside en esa posición de memoria es el sistema operativo (que veremos más adelante), y configurar esa posición de memoria es una instrucción privilegiada, así que no puede haberlo hecho el usuario normal, tiene que haberlo hecho el propio sistema operativo durante su inicialización.

Al juntar ambas cosas, sabemos que tenemos dos modos: el modo normal, que es como se ejecutan todos los programas de usuario. Y el modo privilegiado, que es como se ejecuta el sistema operativo. Cuidado, porque este modo privilegiado no es el usuario Administrador o el usuario root. En ambos casos tanto root como Administrador ejecutan en modo normal. Lo del modo privilegiado es aún más profundo que eso. Ni siquiera el usuario Administrador puede ejecutar las instrucciones privilegiadas directamente, tiene que hacerlo a través del sistema operativo.

El caso es que estamos continuamente con el sistema operativo para acá, el sistema operativo para allá… hombre, lo he hecho porque a estas alturas de la película seguro que sabes lo que es un sistema operativo (Windows, Linux, Android, Mac, iOS… son nombres de sistemas operativos). Pero seguro que muchas de las cosas que vamos nombrando te quedan un poco en el aire. Pues a eso dedicaremos los siguientes capítulos: al sistema operativo.

1. Aunque en los últimos años los sistemas basados en Arduino están tomando mucho empuje.
2. Además, como ya mencionamos en capítulos anteriores, en los sistemas modernos esas instrucciones están microprogramadas. No obstante, eso no afecta al nivel al que estamos viendo los ordenadores, así que lo vamos a obviar.
3. NdE: En concreto son las CPU’s de los modernos mainframes de IBM, que tienen entre su juego de instrucciones una concreta para hacer un “Insertion Sort”.
4. Cuidado de todos modos: en esta discusión, la multiplicación y cosas así siguen siendo “instrucciones sencillas”.

En los últimos capítulos de esta serie nos hemos dedicado a estudiar cómo funciona un ordenador sencillo, sencillísimo, minimalista: el C16A. Luego lo ampliamos, inventando el ordenador C16B, para poder hacer llamadas a subrutinas. En la última entrada hablamos del compilador. Ahora vamos a presentar la última de las modificaciones: el C16C.

La arquitectura de este sistema es la siguiente:

¡Pero si casi no cambia nada!

Pues sí, cambia un montón. Es solamente un concepto nuevo el que vamos a introducir, pero todo el diseño de los sistemas modernos se basa en él. Vamos a introducir el concepto de interrupción.

Probablemente no recuerdes ya el programa que hicimos hace un par de capítulos para leer del teclado y actuar en consecuencia… vamos a pegarlo de nuevo, para que puedas recordarlo.

No hace falta que lo recuerdes en detalle. Solo es importante que te fijes en las dos primeras líneas: ¿cómo se lee una tecla pulsada por el usuario?

Lo que hace es mirar a ver si el usuario ha pulsado una tecla, y volver a mirar, y otra vez… y otra y otra… así hasta que el usuario efectivamente pulsa una tecla. Esto es lo que se llama espera activa: en lugar de estar simplemente esperando, está preguntando continuamente si ya está. La espera activa tiene sus aplicaciones, sobre todo el si el sistema no permite hacer otra cosa, pero como norma general es una chapuza. Date cuenta de que hemos dicho, por ejemplo, que en los sistemas modernos si ejecutamos NOP le estamos diciendo al sistema que no tenemos nada que hacer (por ejemplo para que aplique políticas de ahorro)… pero aquí no estamos “haciendo nada”, sino que estamos haciendo algo: preguntar si ya hay una tecla pulsada.

Es como cuando tu jefe te encarga que hagas algo, y cada cinco minutos pasa por tu sitio y te pregunta “¿ya has terminado?”. Y cinco minutos después, otra vez. Y otra, y otra. A la cuarta vez le dices, conteniendo la ira, “déjame en paz, ya te avisaré yo cuando termine”. Bueno, al menos en este ejemplo el jefe te ha encargado algo. La espera activa es peor aún: es como si cada cinco minutos te pregunta tu jefe “¿ha llamado algún cliente?”. “Déjame en paz, ya te avisaré si llama algún cliente”…

Bien, pues eso es una interrupción: la CPU no le pregunta al teclado continuamente si tiene algo nuevo, sino que la CPU sigue a su rollo, y el teclado le avisará cuando tenga algo nuevo.

¿Cómo lo hará? Lo hará a través de la línea de IRQ que tiene la CU (IRQ viene de Interruption ReQuest, petición de interrupción). La línea de IRQ funciona por flanco de subida (como los biestables que veíamos hace mucho): si pasa de 0 a 1, es que hay una petición de interrupción del teclado. Esa es la forma en la que el teclado le dice a la CPU que el usuario ha pulsado una tecla.

El esquema del teclado es muy sencillo: simplemente se pasan todas las teclas por un AND, de modo que casi siempre valdrá 0. Cuando el usuario pulse una tecla pasará a valer 1 por un breve instante, pero será suficiente, dado que la línea de interrupción funciona por flanco de subida.

Y una vez que ya tenemos la línea de IRQ, ¿cómo funciona? ¿Qué hace la CU con ella? Lo que hace la CU es lo siguiente:

• Termina de ejecutar la instrucción que estuviera ejecutando. Recuerda que una instrucción puede tardar más de un ciclo de reloj. Las instrucciones que nosotros hemos hecho en este ordenador son sencillitas, pero hay instrucciones más complejas (en el próximo capítulo veremos más sobre esto).
• Guarda en la pila el “estado del sistema”. En nuestro caso el estado del sistema son los dos registros: PC y AC. Vale, pues los guarda en la pila.
• Salta a la posición 0×100 y ejecuta lo que haya allí. Es decir, pone en PC el número 0×100 y continúa.

¿Te das cuenta de que es algo parecido a las subrutinas? Es una forma un poco especial de subrutina, pero vaya… se parece, en cierto modo. Así que habrá algún tipo de forma de retorno, ¿no? Sí, efectivamente: se define una nueva instrucción llamada RTI (ReTurn from Interruption, retorno de interrupción) que hace básicamente lo contrario: saca de la pila el valor de AC que habíamos guardado y lo restaura; saca de la pila el valor de PC que habíamos guardado y lo restaura. Como antes, no vamos a ver en detalle cómo se hacen estas dos operaciones, pero a estas alturas espero que no te resulte completamente mágico el cómo lo hace la CU.

Entonces, ¿cómo quedaría nuestro programa?

La mayor parte del programa es el mismo, pero las diferencias son brutales. Date cuenta de que, nada más empezar, en las líneas 0×000 y 0×001, simplemente ¡entra en el bucle de fin! ¡Es decir, ya se queda sin hace nada! La diferencia ahora es que a partir de la línea 0×100 hay cosas. La posición 0×100 es a donde saltará la ejecución cuando el usuario pulse una tecla… y a partir de ahí, es exactamente igual que en el programa anterior: multiplica, espera durante unos segundos y escribe la tecla pulsada en pantalla… y después retorna de la interrupción, el RTI de la línea 0×111. Es decir, vuelve al bucle a no hacer nada (es decir, hasta que el usuario pulse otra tecla, en cuyo momento volverá a saltar la interrupción y vuelta a empezar).

Puede parecer que es una tontería, y que no ha cambiado mucho… ahora intentaré convencerte de lo contrario. Pero primero, asegúrate de entenderlo, incluso aunque creas que el concepto no es importante. La CPU puede estar ejecutando cualquier cosa: cuando se levante una interrupción a través de la línea IRQ, ejecutará esa especie de subrutina y luego seguirá por donde iba.

La potencia de este método viene del hecho de que en los ordenadores reales no existe una entrada de interrupción, sino muchas. Vamos a poner unos cuantos ejemplos, pero no te fijes en el orden para ver su importancia: las del final son muy muy importantes también.

• Cuando el usuario pulsa una tecla.
• Cuando la pantalla ha terminado de escribir lo que le han pedido.
• Cuando entra sonido a través del micrófono de la tarjeta de sonido.
• Cuando ha terminado de reproducir (a través de la tarjeta de sonido) lo que le hemos pedido que reproduzca.
• Cuando entran datos a través de la tarjeta de red.
• Cuando la tarjeta de red ha terminado de enviar los datos que le habíamos pedido que enviara.
• Cuando existe una división por cero. Sabes que dividir cualquiercosa/0 es un error… pues bien, eso levanta una interrupción que viene de la ALU.
• Cuando se intenta acceder a una zona de memoria que no existe o sobre la que no tenemos permiso (veremos más sobre esto más adelante).
• Cuando lo pide el programa. Suele haber una (o varias) instrucciones que generan una interrupción. También veremos esto más adelante. Esto es lo que se llama una “interrupción por software”.
• Periódicamente, según un reloj. Por ejemplo, cada 1ms.
• Cuando se prevé un fallo de alimentación.
• Cuando ha terminado de escribir en disco lo que le hemos pedido.

Prácticamente cualquier cosa importante que pueda ocurrir en un ordenador hoy en día genera una interrupción.

La gracia de esas interrupciones es que pueden ocurrir en cualquier momento… ¡incluso mientras estoy ejecutando otra interrupción!^[1]

Volveremos sobre esto más adelante, cuando veamos los sistemas multiproceso, pero los sistemas operativos modernos hacen absolutamente todo su trabajo en base a interrupciones. Un sistema operativo moderno, una vez que se ha inicializado, simplemente se queda en un bucle sin hacer nada hasta que salta una interrupción. Lo veremos más adelante con más detalle, de momento céntrate solo en conocer el concepto de interrupción y cómo opera.

En el próximo capítulo terminaremos este nivel de la máquina nombrando alguna de las diferencias más importantes entre los sistemas reales y estos ejemplos de máquinas académicas.

1. No obstante, suele haber algún mecanismo de priorización, porque algunas de las interrupciones son muy importantes y no se deben interrumpir. Por ejemplo, se pueden numerar y una interrupción solo puede ser interrumpida por otra interrupción de número menor.

En el último capítulo de esta serie presentamos el ordenador C16B y el concepto de subrutina, y escribimos un programa que calculaba el factorial de un número. Pero vimos que el programa empezaba a ser demasiado grande y que nos iba resultando útil describir su funcionamiento con algún tipo de pseudolenguaje, así que describíamos nuestro programa tal que así:

numero = 6
resultado = 1
mientras (numero != 0) {
  resultado = multiplicar(resultado,numero)
  numero = numero -1
}
# El resultado está en resultado
subrutina multiplicar(p, q) {
  res = 0
  mientras (p != 0) {
    p = p -1
    res = res + q
  }
  devolver res
}

Supongo que te resulta mucho más sencillo de entender, ¿verdad?

Haz ahora un ejercicio: en el capítulo anterior lo que hicimos fue escribir el programa en ensamblador y luego describirlo de esta forma un poco más abstracta. Pero… ¿serías capaz de hacer lo contrario? Es decir, si te doy el programa descrito en esta forma abstracta, ¿serías capaz de convertirlo en las instrucciones de ensamblador correspondientes?

Espero que la respuesta sea un sí, claro.

Pues eso es lo que hace un compilador: primero nos inventamos un lenguaje que sea más cercano al natural (no te sorprenderá que se base en el inglés) y luego el compilador traduce eso a código máquina. Por ejemplo, si quisiéramos escribir ese mismo programa en (algo parecido a) C,^[1] haríamos lo siguiente:

int multiplicar(int p, int q) {
  int res = 0;
  while (p != 0) {
    p = p - 1;
    res = res + q;
  }
  return res;
}
int numero = 6;
int resultado = 1;
while (numero != 0) {
  resultado = multiplicar(resultado, numero);
  numero = numero -1;
}
// Al llegar aqui, resultado ya tiene el factorial

Supongo que, a poco inglés que sepas, eres capaz de deducir qué es lo que hace este código en C.

Pues bien, con esto hemos inventado los lenguajes de programación.

El programa, escrito en este lenguaje de programación, se llama “código fuente”. Lo que se carga en la memoria del ordenador para ser ejecutado se llama “código objeto” o “binario” u “objeto” u otras cosas así. El proceso de convertir el código fuente en el código objeto se llama “compilar”.

¿Podríamos hacer un programa que tome el código fuente y genere automáticamente el código binario? Sí, claro que podemos, no es más que una traducción de un formato a otro. No solo eso, sino que, además, dada la complejidad de los ordenadores actuales, el nivel de abstracción de los lenguajes de programación modernos y la potencia de los compiladores de hoy en día, el código binario que generan los compiladores es a menudo mejor que lo que podría lograr un ser humano típico escribiendo directamente el programa en ensamblador. No vamos a ver nada sobre teoría de compiladores, supongo que entre lo que hemos visto antes y estos párrafos eres capaz de entender que hacer esa traducción, esa compilación, es posible.

Lo que hemos visto es un lenguaje de programación, el lenguaje C, que es de muy bajo nivel: se dice que un lenguaje de programación es de más bajo nivel cuanto más cercano al código ensamblador está en su nivel de abstracción. C es un lenguaje de muy bajo nivel (hasta el punto de que a menudo se le llama, peyorativamente, “ensamblador de alto nivel”, para indicar que es “poco más que el ensamblador”).^[2] Otros lenguajes también de bajo nivel son Pascal o Fortran.

Fíjate en que en estos lenguajes se definen estructuras de datos y funciones (lo que nosotros hemos llamado subrutinas) que se van llamando unas a otras astutatemente para operar con dichos datos… y poco más. Esto es lo que se llama programación procedural o programación imperativa.^[3]

Pero a la gente rápidamente se le ocurrió que podía dar un nivel más de abstracción, inventando otros paradigmas de programación. Así, por ejemplo, se inventó la programación orientada a objetos. En ella se definen objetos, que tienen una serie de propiedades  y de operaciones. Puede parecer que es muy parecido a la programación imperativa, y es que de hecho está basada en ella. Su mayor potencia radica en que los objetos “heredan” cosas unos de otros. Así por ejemplo, podemos tener un objeto de tipo Vehículo, que tiene una propiedad que es la Velocidad y una operación que es Acelerar. Podemos también tener un objeto de tipo Coche, que es “hijo” del tipo Vehículo. Como es hijo de Vehículo, tiene todas sus propiedades y operaciones, pero puede también definir propiedades y operaciones nuevas. Por ejemplo, puede tener la propiedad NumeroDeRuedas y la operación CambiarRueda… pero ojo, que sigue teniendo la propiedad Velocidad y la operación Acelerar. O también podemos tener otro tipo, el tipo Barco, que también es hijo de Vehículo, con un par de propiedades nuevas Eslora y NumeroDeCubiertas, y con la operación Atracar. Como Barco es hijo de Vehículo, tiene la propiedad Velocidad y la operación Acelerar, pero como no tiene nada que ver con Coche no tiene ninguna operación llamada CambiarRueda.^[4] En fin, es un ejemplo muy tonto, pero combinando adecuadamente esos objetos y operaciones se pueden hacer cosas muy complejas.

La programación orientada a objetos probablemente es hoy en día el paradigma más extendido, en lenguajes como C++, Java, Objetive C, C#, PHP…^[5] Existen otros paradigmas, pero, y espero que sus partidarios no se me tiren al cuello, no están tan extendidos: programación funcional, programación lógica, programación declarativa… sus partidarios sostienen que SUSTITUYA-AQUÍ-SU-PARADIGMA-FAVORITO le dice al ordenador qué tiene que hacer, mientras que la programación imperativa (y su hija, la programación orientada a objetos) le dice al ordenador cómo tiene que hacerlo, y que por eso SUSTITUYA-AQUÍ-SU-PARADIGMA-FAVORITO es mejor. Ni que decir tiene que algo de razón lleva, pero limitar la discusión a “X es mejor que Y” es muy superficial.

No vamos a entrar más en detalle en teoría de lenguajes, pues llevaría para un libro entero. Este capítulo, que ha sido ligerito en comparación de a lo que estamos habituados, servirá para que veas que en el futuro veremos muchas cosas de una forma más abstracta, sin escribir tanto ensamblador. En el próximo capítulo veremos la última de las versiones de C16, el C16C.

1. C es un lenguaje de programación, probablemente el más famoso de todos.
2. Ojo: “bajo nivel” no significa que sea malo. Hace referencia a su nivel de abstracción, no a si es bueno o malo.
3. Su definición formal es mucho más farragosa, algo así como “el paradigma que se basa en definir un estado y cambios sobre dicho estado”… que en el fondo no es más que lo que nosotros sabemos que es un circuito secuencial.
4. Bueno, es su “hermano”, pero en este paradigma eso no importa.
5. Estoy obviando que muchos de estos lenguajes son interpretados, o se ejecutan sobre máquinas virtuales… si no sabes de qué hablo, no te preocupes, no es necesario.

Un bit es un dígito en el sistema binario, y es el elemento básico de los circuitos eléctricos digitales y, por tanto, de los ordenadores. No voy a recordar lo que es el sistema binario porque ya se ha explicado; baste con recordar que cualquier número lo podemos traducir a binario, 13 en decimal es 1101 en binario, y cada uno de los unos o ceros que forman el número es un bit. Eso en la parte púramente matemática; en electrónica representamos cada bit como un voltaje alto o bajo, o como una bombilla encendida, , que sería un 1, o una bombilla apagada, , que sería un cero.

Hasta aquí la parte clásica; para introducir ahora el concepto de qubit tenemos que tener en cuenta, si recuerdas la serie Cuántica sin Fórmulas, que al llegar al nivel cuántico las cosas no suelen estar encendidas ni apagadas “de verdad”, sino que están en un estado que es una especie de mezcla de ambas cosas. Eso es un qubit: no tenemos la bombilla encendida ni apagada, sino que está “en otro estado” que no es ni encendido, ni apagado. Recuerda, esto es muy importante, porque no significa que la bombilla esté encendida a medias, ni rota, ni nada similar: está a la vez encendida y apagada.

¿Cómo vamos a representar esto? Vamos a usar la llamada notación bra-ket, que Pedro ya nos introdujo en el link que enlacé antes: ¡repásatelo! Vamos a tener dos posibles kets, que son autoestados de la bombilla: el ket |>, que representa una bombilla encendida, y el ket |>, que representa una bombilla apagada. Pues bien, el estado general de nuestro qubit va a ser lo que se llama una superposición de los dos estados, a·|>+b·|>, donde a y b son números complejos.

Varios apuntes aquí: el primero, recuerda que esto no significa que esté medio encendida ni nada similar, sino que está a la vez encendida y apagada, en un cierto sentido. El segundo, voy a intentar evitar usar números complejos porque sé que son mucho más liosos; casi siempre podré conseguirlo y usar números reales, aunque cuando veamos algunas puertas será necesario meternos un momento en ellos. Si te parecen muy difíciles los números complejos sáltate ese momentito y ya está. El tercero, a y b no son números independientes (muy remarcado porque es muy importante). Existe una cosa que se llama normalización, que es básica para poder calcular probabilidades y demás, y nos obliga a que ambos números sigan una relación, |a|²+|b|²=1, que significa que el cuadrado del módulo de a más el cuadrado del módulo de b tienen que sumar 1. Si, como hemos dicho, nos restringimos a números reales, se puede escribir esto más fácilmente: a²+b²=1. De aquí podemos ver que tanto a como b tienen que ser números que estén entre -1 y 1, y que cuanto más lejos del cero esté uno, más cerca del cero estará el otro.

Hasta aquí las matemáticas. ¿Qué quiere decir esto? Pues quiere decir que un qubit no vamos a saber si es un 1 o un 0 mientras no lo miremos. Y no sólo es que no lo sepamos, es que hasta entonces sólo hay una probabilidad de que sea 1 y una probabilidad de que sea 0, pero el qubit no es ni cero ni uno. Pero al mirarlo tendremos que ver necesariamente un 1 o un 0, con una cierta probabilidad. ¿Y qué probabilidad? Pues precisamente a² de que sea 0, es decir, de que la bombilla esté apagada, y b² de que sea 1, es decir, de que la bombilla esté encendida.

Un ejemplo (y permitidme que cambie los nombres a los kets: ahora al ket |> le llamaré |1> y al ket |> le llamaré |0>, pero podéis seguir pensando en bombillas al verlos, si así os resulta más fácil). Supongamos que nuestro qubit está en el estado 0.8·|0>+0.6·|1>. Primero vamos a comprobar que cumple la relación que pusimos arriba: (0.8)²+(0.6)²=0.64+0.36=1, por lo que sí, la cumple. Esto nos quiere decir que es un estado válido, un qubit puede estar en este estado. ¿Qué probabilidades hay de que al mirar el qubit sea 1, y qué probabilidades hay de que sea 0? Pues la probabilidad de que sea 0 es simplemente (0.8)², es decir, 0.64, es decir, un 64%. Y la probabilidad de que sea 1 es (0.6)², es decir, 0.36, es decir, un 36%. ¡Anda, las probabilidades suman 1! ¡Qué casualidad! Pues no, no lo es, para eso precisamente era la normalización. Al normalizar, las probabilidades salen así de fácil.

Una cosa fastidiosa y a la vez totalmente necesaria para la CC es que cuando miramos ese qubit, y tenemos unas probabilidades de ver un 0 o de ver un 1, no solamente vemos el qubit: lo cambiamos. Y lo cambiamos a un nuevo estado perfectamente definido y perfectamente no cuántico. Si miramos y vemos un 0, ahora el estado será |0>. Si miramos y vemos un 1, ahora el estado será 1. Y se nos “borrará” toda la información extra (el a y el b, el 0.8 y el 0.6) que teníamos antes. Esa información desaparece totalmente, y no hay manera de recuperarla. Cuando nosotros queramos medir el qubit, entonces eso estará bien, porque es lo que queríamos (y veremos que todos los algoritmos cuánticos miden qubits al final). Pero si por el contrario “medimos sin querer” en mitad de un cálculo… perderemos la información y el cálculo saldrá mal. Hay muchas formas de “medir sin querer”, y las comentaré cuando lleguemos a cómo se construye un qubit en la realidad – probablemente, cerca del final de la serie.

Ahora los más avispados estaréis preguntándoos: ¿cómo sabemos el estado del qubit, ese 0.8·|0>+0.6·|1>, si no lo hemos mirado? Pues es muy simple: en general, no lo sabemos. Pero la Naturaleza, de una forma que no entendemos completamente, sí lo sabrá, y eso a nosotros nos basta. Nosotros simplemente comenzaremos con un estado |0> o |1>, que sabemos ponerlos con mucha facilidad (¡mirando!) y aplicaremos puertas lógicas cuánticas que cambiarán el estado. En principio podemos ir calculando qué cambios hace exactamente, pero la gracia de la computación cuántica es que no lo necesitaremos: la Naturaleza lo hará por nosotros y nos facilitará mucho el trabajo.

Y hasta aquí lo que es un qubit. Cuando hay más de un qubit las cosas cambian, pero antes de meternos en eso, en la próxima entrada veremos las puertas lógicas de un qubit.

En el último capítulo de esta serie veíamos un programa relativamente complejo que permitía temporizar la salida hacia la pantalla dependiendo de la tecla que habíamos pulsado… pero decíamos que había algunas cosas que eran un poco chapuceras. No eran culpa del diseño del programa… es que con ese ordenador no se podía hacer mucho más. Así que vamos a mejorar el ordenador C16A con una pila, y lo vamos a llamar C16B.

La arquitectura de nuestro nuevo ordenador será la siguiente:

Supongo que te has dado cuenta de que, arquitecturalmente, hay poca diferencia: existe un nuevo registro que se llama SP (del inglés Stack Pointer, puntero de la pila). Como probablemente no sabes lo que es una pila, vamos a verla primero a nivel teórico y luego vemos su uso en el C16B.

Una pila almacena “cosas” (en nuestro ejemplo almacenará números enteros de 16 bits), y tiene dos operaciones: PUSH y POP. En este contexto se suelen traducir como “meter” y “sacar” respectivamente. O también “poner” y “quitar”. O mejor dicho: no se traducen; todo el mundo usa los términos en inglés. La gracia es que la pila es un sistema LIFO (Last In First Out, el último en entrar es el primero en salir): si vas metiendo uno o más elementos en la pila, cuando saques, sacarás el último que metiste. Podemos imaginárnoslo como una caja profunda o un barril en el que metemos artículos relativamente voluminosos: metemos el Primero, y se va al fondo; metemos el Segundo, y se queda sobre el Primero; metemos un Tercero, y se queda sobre el Segundo; si ahora sacamos, sacaremos el Tercero; si volvemos a sacar, sacaremos el Segundo. Quizá el siguiente dibujo te ayude a entenderlo:

Date cuenta de que conceptualmente PUSH tiene un “parámetro”. Es decir, cuando hacemos PUSH hay que decir PUSH de ¿qué?. O sea, ¿qué es lo que hay que meter en la pila? En cambio, cuando hacemos POP, lo que obtenemos es lo que haya en lo alto de la pila,^[1] no tenemos que decir qué es lo que queremos sacar… lo que sí que hay que decir es qué hacemos con eso que hemos sacado.

Vamos a implementar entonces nuestra pila al final de la memoria principal. Cuando arranca el sistema, hacemos que el registro SP contenga la dirección 0x7FF. Cuando nos pidan meter algo en la pila (PUSH), lo que haremos es escribirlo en la posición de la memoria donde diga SP, y luego restar 1 de SP. Cuando lo que nos pidan sea sacar de la pila (POP), recuperaremos lo que haya en la dirección siguiente a la que apunte SP, y luego sumaremos 1 a SP. A ver si el siguiente dibujo te ayuda a entenderlo:

¿Lo ves? Empieza apuntando al final de la memoria. Cuando hacemos la operación PUSH 1234, se introduce ese 1234 al final, y se resta 1 a SP. Luego se hace PUSH de otro número: el 9876. Después se hace POP, de modo que el 9876 sale de la pila y SP apunta una posición más abajo de nuevo, en este caso al 1234. Fácil, ¿verdad?

Bueno, pues vamos a añadir cuatro instrucciones más a nuestro ordenador. Recordarás que habíamos reservado 4 bits para las instrucciones (16 combinaciones posibles), pero solo teníamos 8 instrucciones usadas. Vamos a añadir otras 4:

Esta vez no vamos a ver en detalle cómo se hacen estas instrucciones. Cuando vimos el C16A lo vimos con detalle, pero ahora ya sería detallar demasiado. Además de las dos instrucciones que ya hemos visto para operar con la pila, PUSH y POP, hay otras dos que parecen un poco especiales, ¿no? Es decir, también parece que operan con la pila, pero que también hacen algo más, ¿no? Recuerda que PC (Program Counter) apunta a “la siguiente instrucción a ejecutar”, así que “poner X en PC” significa “saltar a X”. Es decir, son como PUSH y POP respectivamente, pero lo que guardan/sacan es el PC, no el acumulador; y además, saltan.

Vamos a ver para qué sirven con un ejemplo (esta vez no vamos a usar el teclado ni la pantalla para nada, para simplificar el ejemplo al máximo): vamos a calcular el factorial de un número.

Es decir, si el número es el 6, vamos a hacer 6x5x4x3x2x1 = 720. Pero claro, nuestro ordenador no sabe multiplicar… solo sabe sumar. En el último artículo vimos un truco para multiplicar números enteros positivos: multiplicar PxQ es sumar Q veces P. Pero una preguntita… ¿esto de multiplicar un número por otro no es algo muy habitual? ¿No podría ocurrírsenos una forma de escribir el “subprograma de multiplicación” una sola vez y luego usarlo tantas veces como necesitemos? Muy buena idea, vamos a ello. El programa que hace eso es el siguiente. Prepárate, porque es bastante largo, pero es probablemente lo más largo que vamos a ver en la serie. Esta vez, como es bastante largo, vamos a escribir a la izquierda las direcciones de memoria, porque si no, nos perdemos.

A ver si logramos entenderlo. Lo mejor es quitarnos rápido de en medio las cosas que son fáciles: las líneas con el /HALT son igual que antes, para terminar ahí. /NUMERO contiene inicialmente el número del que queremos calcular el factorial y /RESULTADO es donde dejaremos el resultado, obviamente, el factorial.

Luego, lo mejor es ir entendiendo bloques sencillitos. Veamos… las líneas 0×000 a 0×001 y 0×008 a 0x00B, ¿qué hacen? Ojo, que estoy olvidándome de momento de lo que hay entre medias: solo esas seis líneas. ¿Qué hacen? Ya lo hemos visto antes: carga una dirección de memoria y la van decrementando hasta que llega a 1. Esa dirección de memoria es /NUMERO, así que esas 6 líneas van contando hacia atrás 6, 5, 4, 3, 2, 1… y entre medias parece que hacen algo con ese /NUMERO. ¿Entendido esto?

Entonces, ¿qué está haciendo con ese /NUMERO entre medias, en las líneas 0×002 a 0×007? Primero mete /NUMERO en la pila. Luego mete /RESULTADO en la pila. Luego llama a /MULTIPLICAR. Y luego saca algo de la pila y lo guarda en /RESULTADO.

Uhm… no acabo de entenderlo del todo…

¿Y si intentamos entender qué hace esa llamada a /MULTIPLICAR? Recuerdas que el CALL /MULTIPLICAR lo que hace es saltar a /MULTIPLICAR, metiendo previamente en la pila el valor actual de PC, ¿verdad? Y una vez que llega a /MULTIPLICAR, ¿qué hace? Son las líneas 0×011 a 0×022. De esas líneas, si lo miramos con cuidado, hay un pedazo que ya sabemos qué hace: lo que hay entre la 0×017 y la 0x01E es lo mismo que en el artículo anterior usábamos para multiplicar dos números: sumar P veces Q. El resultado de esa multiplicación acaba en /RES.

Así que lo único raro es lo que hay alrededor de eso. Lo que hace es: sacar un valor de la pila y guardarlo en /RETORNO. Sacar un elemento de la pila y guardarlo en /P. Sacar otro valor de la pila y guardarlo en /Q. Luego multiplica con el bucle que ya hemos visto. Luego mete /RES en la pila. Luego mete /RETORNO en la pila. Y luego llama a RET. Sabemos que RET lo que hace es saltar a donde diga la última entrada de la pila.

¿Lo vas viendo? Vamos a verlo un poco más en abstracto:

La gracia de esto es que lo que el “programa principal” mete en la pila, la “subrutina” lo saca y lo utiliza. Cuando acaba, mete en la pila el resultado, que será extraído por el programa principal.

¡Estupendo! ¡Eso es una subrutina!^[2]

Todas las subrutinas funcionan más o menos así:

• Quien va a llamarlas mete en la pila los parámetros de la subrutina, en un cierto orden prefijado que es el que espera la subrutina.
• La subrutina hace lo que tenga que hacer, que puede ser incluso llamar a otras subrutinas (¡o incluso llamarse a sí misma!), y pone el resultado en la pila.^[3]
• La subrutina termina devolviendo el control a su llamador (especificando la próxima instrucción a ejecutar, que es la siguiente a la instrucción CALL).
• Quien llamó saca de la pila el resultado y continúa su proceso.

¡Es un invento maravilloso! Podemos hacer subrutinas para multiplicar, restar, contar, comparar, esperar… Y después, las vamos combinando unas con otras para hacer rutinas más complejas: rutinas que hagan logaritmos, que calculen sudokus o que preparen café con leche. Y luego, desde el programa principal las vamos llamando. Esta es la única forma razonable de hacer programas complejos. Gran parte del trabajo de los programadores consiste en organizar estas subrutinas de forma lo más inteligente posible para que el programa funcione rápido, sea fácil de mantener en el futuro, se programe rápidamente…

Por lo tanto, hemos hecho una subrutina que multiplica los dos números que le pasemos como parámetros. Recapitulemos entonces: teníamos un bucle que contaba de 6 hacia abajo, hasta llegar a 1: 6, 5, 4, 3, 2, 1. Y, dentro de ese bucle, tenemos que el resultado es el resultado [anterior] multiplicado por el número. Es decir, vamos multiplicando 1×6. Luego el resultado de eso lo multiplicamos x5. El resultado de eso x4… Y así hasta llegar a 1. ¡Eso es el factorial! Lo hemos conseguido: nuestro programa calcula el factorial de un número.^[4]

Muchas veces utilizamos algún tipo de pseudocógico para ir explicando lo que va haciendo de forma un poco más abstracta. Por ejemplo, podemos decir:

Fíjate en que es lo mismo, pero puesto de una forma un poco más abstracta… eso es lo que veremos en el próximo capítulo.

1. Técnicamente, en español se denomina la “cabeza de la pila”, y sacar un elemento de la pila con un POP, lo llamamos “descabezar” la pila.
2. Dependiendo del sistema se le llama subrutina, rutina, subprograma, función, procedimiento, método…
3. Por cierto: el factorial lo hemos calculado con un algoritmo iterativo. La forma elegante y sencilla de hacerlo es con un algoritmo recursivo, que se basa en que factorial(N) = N*factorial(N-1). Pero no quería contar ambas cosas a la vez para no liar más a los lectores sin experiencia en estas lides.
4. Date cuenta de que no tenemos ninguna instrucción para comprobar si es un 1, que podríamos ahorrárnoslo, y por eso tenemos que perder el tiempo multiplicando por 1.

En el último capítulo de la serie vimos el “hola mundo” de los programas para el C16A. Hoy vamos a profundizar un poco en él, haciendo un programa un poco más complejo: vamos a hacer un temporizador como el que hicimos con lógica secuencial.

Como antes, vamos a pegar a continuación el diseño del ordenador y el juego de instrucciones:

Recuerda también que estamos usando lenguaje ensamblador para escribir nuestro programa, de modo que lo que escribamos resulte legible con relativa facilidad.

Entonces, como decíamos, queremos hacer un programa que espere 3 segundos y luego escriba una “A” en pantalla . Desgraciadamente, para que la espera fuera de 3 segundos tendríamos que introducir muchas cosas que aún no hemos visto, de modo que tendremos que simplificarlo un poco: vamos a esperar 3000 “ciclos”. Veremos luego cómo ajustarlo para que realmente sean 3 segundos y veremos qué fácil es.

¿Quieres intentar hacer tú el programa? Si sabes programar, te resultará trivial. Si no, dale una pensada antes de seguir.

…

¿Ya?

El programa que lo logra es el siguiente:

Supongo que, como el programa es sencillito, lo entiendes sin problemas. Al empezar, carga en el acumulador el valor que hay en /TIEMPO (es decir, 3000). Luego lo decrementa, por lo que ya vale 2999. Fíjate ahora en el truco: el BRZ de la 3ª línea dice que, si el acumulador es 0, salte a la línea /FIN. Pero el acumulador no es 0, sino 2999, con lo cual no salta, y continúa por la línea 4ª. Pero la línea 4ª es un salto a /ESPERA… pues nada, allá que se va. Es decir, hemos vuelto atrás.

Por lo tanto, volverá a decrementar el acumulador, que pasará a valer 2998. Obviamente, volverá a pasar por el BRZ, y como sigue sin ser 0, volverá a continuar por el BR, que volverá a saltar a /ESPERA… así una y otra vez… ¿cuántas veces? Pues 3000 veces. Porque cuando haya pasado por ahí 3000 veces, esta vez sí, el acumulador valdrá 0, y cuando pase por el BRZ /FIN, como el acumulador sí que será 0, entonces saltará a /FIN. ¿Entendido?

Ya solo queda que, cuando llegue ahí, cargue en el acumulador lo que hay en la posición /LETRA, que es una ‘A’, y lo escribe en la posición /PANTALLA1, que es nuestra pantalla. Finalmente, entra en el mismo bucle infinito que veíamos en el capítulo anterior.

Fácil, ¿verdad?

Bueno, pues hemos conseguido lo que queríamos. Con un pequeño detalle: no sabemos cuánto va a tardar esto en realidad. Pero es más fácil de lo que parece, y nos sirve para demostrar la potencia de esta aproximación. Ahora vamos y encendemos el ordenador, y con un cronómetro medimos el tiempo que transcurre desde que encendemos hasta que se escribe la “A” en la pantalla. Supongamos, por ejemplo, que hemos medido 15s. Entonces ya sabemos que con 3000 “ciclos”, tenemos 15s. Con una simple regla de 3 sabemos que cada segundo son 200 ciclos.

¿Qué debemos hacer ahora para que nuestro diseño de verdad espere 3s? Muy sencillo: cambiamos el programa por el siguiente:

Fíjate en que el único cambio es que en vez de poner 3000 en /TIEMPO, ahora pone 600.

¡Tachán! Ahora ya espera 3s.

¿Y si queremos que, en vez de 3s, espere 11s? Pues lo mismo: ponemos 2200 en la posición /TIEMPO y volvemos a encenderlo.

Date cuenta de la diferencia enorme que esto supone respecto al circuito secuencial que veíamos anteriormente. En aquel momento diseñamos con mucho cuidado un circuito muy sencillo que contaba hasta 3. Pero si queríamos contar hasta 11, por ejemplo, teníamos que cambiar el circuito de arriba a abajo: teníamos que añadir más biestables, cambiar la lógica de realimentación, cambiar la etapa de salida… en fin, había que rehacer el circuito por completo. Ahora, en cambio, tenemos un sistema que es muuuuuucho más complejo inicialmente. Date cuenta también de que ahora tenemos una ALU, una unidad de control, memoria… es mucho más complejo. Pero, a cambio, modificar el tiempo de espera es trivial. Solo hemos tenido que cambiar el valor inicial de una de las palabras de la memoria. Y no solo eso, sino que ahora podemos hacer programas mucho más complejos.

Vamos con un ejemplo. Ten presente que también tenemos un teclado… pues vamos a aprovecharlo. Lo que vamos a hacer es un programa que haga lo siguiente: al arrancar, que no haga nada. Cuando pulse una de las teclas, esperaremos tantos segundos como corresponda al valor decimal de la tecla pulsada y luego mostraremos la tecla pulsada. Por ejemplo, si el usuario pulsa la tecla “F”, esperaremos 70 segundos y luego mostraremos una “F” en pantalla. Si en cambio pulsa la “b”, esperaremos 98 segundos y luego mostraremos la “b” (recuerda que los caracteres de control los pintaremos simplemente como un cuadrado ). Vamos a recordar aquí el teclado para que no tengas que estar yendo a buscarlo.

Bueno, pues el programa que logra eso es el siguiente:

Si nunca has programado, es probable que entender esto te resulte complicado, y tengas que darle un par de vueltas. Lo que vamos a hacer es un programa asequible y voy a ayudarte, pero es posible que requiera que lo leas un par de veces hasta que lo entiendas. Haz el esfuerzo, porque una vez que entiendas esto habrás entendido buena parte del trabajo técnico de los programadores.

Empezamos casi por el final, definiendo las constantes y variables que vamos a usar. Definimos que /SEGUNDO es 200, porque ya hemos medido antes que con 200 ciclos gastamos 1 segundo. Definimos también /PULSADA, /SUMATORIO y /CONTADOR para almacenar variables: en /PULSADA guardaremos la tecla que se ha pulsado. /SUMATORIO y /CONTADOR los usaremos luego para unos bucles… luego los explicamos. /PANTALLA1 y /TECLADO son, como antes, para leer del teclado y escribir en la pantalla.

Bueno, pues empecemos a ejecutar por el principio. Las dos primeras líneas lo que hacen es leer /TECLADO, y si es un 0, volver a la línea 0×000, donde vuelve a leerlo… una y otra vez… hasta que /TECLADO no sea un 0. Si te acuerdas, el teclado empezaba con un 0, y se rellenaba luego el valor de la tecla pulsada. Así que lo que estamos haciendo aquí es esperar a que el usuario pulse una tecla. Cuando la pulse, ya no habrá un 0, y entonces seguirá por la línea 0×002. En las líneas 0×002 y 0×003 simplemente se guarda la tecla pulsada tanto en /PULSADA como en /CONTADOR.

Las líneas desde /MULTIPLICACION hasta /FINMULTIPLICACION, ¿qué hacen? Muy sencillo: sabemos que multiplicar 3*6 es sumar 3+3+3+3+3+3, ¿verdad? Pues eso es lo que hace: si ya he pasado /CONTADOR veces por el bucle, salgo del bucle hacia /FINMULTIPLICACION; y si no, decremento /CONTADOR en uno, para que a la siguiente pasada pueda volver a comprobarlo (líneas 0×004 a 0×007). Dentro del bucle, sumo /SUMATORIO + /SEGUNDO y guardo el resultado en /SUMATORIO (líneas 0×008 a 0x00A). Finalmente, en la 0x00B salto de vuelta a /MULTIPLICACION, para cerrar el bucle.

Es decir, lo que haré es /SUMATORIO = /SEGUNDO + /SEGUNDO +/ SEGUNDO + /SEGUNDO +… ¿cuántas veces? Tantas veces como valiera /CONTADOR inicialmente… es decir, tantas como el valor numérico de la tecla que haya pulsado.

El caso es que antes o después el BRZ de la línea 0×005 saltará a /FINMULTIPLICACION… y en ese momento /SUMATORIO contiene el resultado de la multiplicación. Lo que hay entre la 0x00C y la 0x00F es lo mismo que antes: una espera durante /SUMATORIO ciclos. Es lo mismo que vimos en el primer programa de esta capítulo, así que nos saltamos la explicación.

Finalmente, cuando llega a /FINESPERA, han pasado los segundos acordados,^[1] así que pasamos el valor de /PULSADA (que, te recuerdo, contenía la tecla que habíamos leído del teclado en la línea 0×000) a /PANTALLA1, saliendo por la pantalla. Luego ya solo queda el bucle de fin que hemos usado siempre.

Vamos a repasarlo, de forma un poco más abstracta, a ver si te ayuda a entenderlo:

• Leemos del teclado hasta que lo que leamos sea distinto de 0.
• Guardamos el resultado de la tecla pulsada.
• Multiplicamos el valor de la tecla pulsada por el valor de /SEGUNDO, para saber cuántos ciclos debemos esperar. Pero como nuestra ALU no multiplica, solo suma, tenemos que implementar la multiplicación como sumar nveces:
  • Si ya he sumado esas n veces, he terminado y salgo del bucle.
  • Si no, añado /SEGUNDO al resultado y decremento en 1 el contador para que se vuelva a comprobar en el siguiente paso por el bucle.
• /SUMATORIO tiene el número ciclos que debo esperar. Así que hago una espera como la del primer programa de este capítulo.
• Finalmente, copio la tecla pulsada (que me la había guardado) en la pantalla y entro en la espera de final de programa.

Lo que hemos hecho aquí no está exento de problemas, pero eso lo veremos en próximos artículos. Dedícale una segunda lectura a estos párrafos, porque si no has programado nunca es normal que te resulte un poco complicado de entender.

En el próximo capítulo ampliaremos nuestro ordenador C16A para que haga alguna cosa más, y lo llamaremos C16B.

1. Date cuenta de que hemos despreciado el tiempo que se tarda en calcular la multiplicación, y que eso podría no ser despreciable. Podríamos arreglarlo, simplemente estimando cuánto se tarda en hacer la multiplicación y restándolo antes de hacer la espera. Como lo importante aquí no es si yo sé programar o no, sino cómo funciona la máquina, dejamos eso como ejercicio, si queréis. Como pista, puedes darte cuenta de que el tiempo que se tarda en hacer la multiplicación es lineal con el valor numérico de la tecla pulsada, y eso también es lineal, por requisito, con el tiempo que queremos esperar. En fin, no sigo, que si no lo resuelvo entero.