TEMP

La primera vez que leí en el manual de una computadora legendaria algo parecido a esto: “This is a stored program, parallel sequencial machine”, me pregunté si es posible construir una computadora que no sea todo eso; porque una máquina secuencial paralela con programa almacenado es el de facto estructural de toda computadora desde antes de mi nacimiento.

No siempre fue asi. Las computadoras de primera generación (1940s y principio de los 50s) eran seriadas, es decir, los datos, en su interior, se procesaban bit a bit. Ya Ramington Rand y IBM habían establecido sus respectivos mercados (con este tipo de máquinas) cuando CRAY construyó una “supercomputadora” cuyo sorprendente poder radicaba, entre otros factores, en el hecho de procesar los datos en paralelo… como lo hacemos hoy.

Lo de “stored program”, en cambio, se estableció desde muy temprano. Antes incluso de fabricarse la ENIAC en Estados Unidos y la Colosus en Inglaterra, Alan Turing había captado ya el concepto a nivel teórico y lo había presentado en su modelo de “máquina universal”. Más tarde, Von Neuman construía su EDVAC en Estados Unidos basado en este principio. No obstante, por aquella misma fecha se construyeron máquinas donde el programa y los datos recidían en memorias separadas, siendo la más notable aquella que construyera IBM para la Univercidad de Harvard en 1944, basada en relays. Hoy suele hablarse de “Von Neuman” versus “Harvard” para referirse a la arquitectura de una computadora dada.

En todo lo anterior reflexionaba después de haberme gastado la tarde pensando en un “sub-proyecto” de Heritage/1: un “controlador de dispositivo”. Siempre he pensado que mis periféricos han de ser inteligentes pero no basados en microcontrolador (LSI) sino en lógica discreta como lo es Heritage/1, y había concebido la idea de construir un “generic controller” basado en un simple FSM cuyas tablas de estado estarían almacenadas en una matriz de diodos.

Hoy que me dispuse por fin a desarrollar la idea y, sorprendentemente, el desarrollo me condujo a comprender el significado de “stored program machine”. No llegué a un diseño concreto pero sí, a intimar satisfactoriamente con el concepto, el cual trataré de explicar en lo que sigue.

Imaginemos un Finite State Machine (FSM) cuya tabla de estados se encuentra almacenada en una memoria. La tecnologia empleada (RAM, matriz de diodos, etc) no es importante ahora; lo importante es imaginar cómo está estructurado el dato que contiene y cómo el FSM hará uso de él.

El objetivo de la máquina es usar el FSM para armar secuencias. Cada locación de memoria representa un paso de secuencia. Por cada locación, cada bit representa una señal se salida. La mayoría de las salidas constituyen “señales de control” de la máquina; algunos pocos bits de salida representan el proximo estado de la FSM, es decir, la “dirección” del próximo paso.

Este arreglo no iría mucho más lejos si no existiese la necesidad de tomar desiciones en base a los datos de entrada. En este punto me encontraba cuando me vi forzado a establecer similitudes entre mi FSM y una computadora como Heritage/1.

¿Qué hace una computadora, a fin de cuentas? Correr secuencias… ¡y nada más! La grandeza está en que dichas secuencias no son fijas sino que toman diferentes rumbos en dependencia de los datos de entrada y los resultados intermedios. Y más grandioso aún es el hecho de que una buena parte de esos “datos” constituyen “instrucciones” (direccionan el FSM) es decir, son el programa en sí: el software.

Esa es, justamente, la esencia del concepto de “programa alamacenado”: el programa mismo es un elemento de entrada, lo mismo que los datos, y en base a ellos, se genera una u otra secuencia.

Hay otro concepto clave en el cual no había reparado sino hasta hoy: la toma de desiciones (próximo estado del FSM) también depende de condisiones establecidas con anterioridad por los resultados intermedios. Es el caso de un resultado negativo después de una suma, por ejemplo. En las computadoras, esto suele recordarse en el “registro de banderas” (Flags Register).

Regresando a mi FSM, imaginemos su tabla de estados dividida (para mejor organización) en “sub-secuencias” de 4 pasos cada una. Esto tiene implicaciones para el direccionamiento de la tabla: de los N bits de dirección, alimentaremos los 2 menos significativos desde un contador de 2 bits cuya entrada está alimentada, a su vez, de un reloj (tren de pulsos). Los N-2 bits restantes servirán para direccionar subsecuencias.

Dije antes que, de cada locacion, unos pocos bits de salida representan el “proximo paso” de la secuencia. Digamos que son estos, M bits, y los conectaremos para direccionar, no secuencias sino subsecuencias. De modo que nuestro FSM puede contener hasta 2^M subsecuencias.

Regresando a la comparación de mi FSM con una computadora, las “subsecuencias” pueden verse como “instrucciones”. La diferencia es que estas no se encuentran en la misma memoria donde reciden los datos sino en memoria separada. Pero eso no es todo; la máquina que tenemos hasta ahora, todavía no funciona porque no es capaz de tomar desiciones en base a los datos de entrada (los verdaderos datos que reciden en la memoria de datos).

Para ello solo tenemos que añadir un Flags Register, cuyas salidas participan en el direccionamiento de la Tabla de Estados. Ya hemos tomado los dos primeros bits para la subsecuencia; ahora tomaremos los 4 siguientes procedentes del Flags Register (o sea, cuatro flags).

La máquina tendrá, por supuesto, registros y algún medio para procesar datos (un ALU por ejemplo). Las entradas de los Flags proceden de esos circuitos, es decir, las banderas se ponen o quitan en dependencia de resultados intermedios, como se quería.

Mi propuesta consite en que, con estos pocos medios, se puede construir una máquina computadora donde el software no recida “como dato” en la misma memoria donde están los datos verdaderos, sino como Tabla de Estados del FSM, en memoria separada. La máquina es capaz de tomar desiciones en base a resultados intermedios gracias al Flags Register y puede, en principio, realizar labores tan complicadas como sea posible “programar” en una Tabla de Estados que sea, a su vez, factible de ser construida.

Mi intención, sin embargo, no es teórica sino práctica. Pretendo valerme de esta técnica para proveer de alguna (escasa) intelegencia a los Device Controllers de Heritage/1.