Ocho bits versus dieciséis

NOTA: Heritage/1 presenta una arquitectura de (estrictamente) 16 bits y no tengo intenciones de cambiarla. Lo que sigue, es tan solo una reflexión al margen.

Mi "amor a primera vista" por los 16 bits parte de: (1) la simetría entre el tamaño de la dirección y el dato en una máquina factible de ser construida y (2) el hecho de ser este el tamaño tradicional (y cómodo) para un número entero.

Tal vez en el contexto de una aplicación típica los números enteros no resaltan como protagonistas de la acción, papel que queda reservado para los números racionales (punto flotante). Sin embargo, debajo del tapete, tanto el OS como la aplicación misma manejan un gran número de estructuras en memoria (por ejemplo, arreglos) cuyo acceso descansa en índices que no pueden ser sino enteros. Y estando el espacio direccionable de la máquina limitado a 2**16 locaciones (y por tanto el de cualquier estructura en memoria), un entero de 16 bits resulta más que razonable.

El problema comienza cuando empiezo a considerar otras labores como el manejo de caracteres y una aritmética decimal (BCD).

Los caracteres (ASCII) son de 8 bits, de modo que una memoria alambrada en locaciones de 16 no es precisamente lo "más natural". Por su parte, una aritmética BCD (en contraposición a una de punto flotante) me resulta muy atractiva por su simplicidad y mayores garantías de precisión, pero en ella los números se representan mediante "nibbles" (4 bits), no "words" (16 bits).

En estos momentos estoy haciendo ajustes en mi ALU para garantizar el necesario soporte pues estas labores se resolverán por Software ¡definitivamente! Sin embargo, me pregunto (y de eso trata esta reflexión) si una arquitectura de 8 bits hubiera abordado estos problemas de manera más natural y eficiente.

A decir verdad, siempre vi a Heritage/1 como una minicomputadora de propósito general, es decir, nunca me senté a imaginar un uso específico para ella. De ser ese el caso, me hubiera enfocado en un diseño "optimizado" para ese uso.

Digamos, por ejemplo, que la máquina está pensada para manejar un sistema contable. Esto implica un gran número de usuarios, generación de reportes y manejo de números con dos o tres dígitos decimales de precisión. Siendo así, el énfasis debería ponerse en los periféricos (terminales, impresora, storage), manejo de texto y una aritmética racional simple como BCD.

Para los periférico hubiera adoptado la enseñanza de IBM/360: "canales" (minicomputadoras adicionales optimizadas para entrada/salida). Aunque creo que mi solución (periféricos bufereados e "inteligentes") no dista mucho de ello.

Para el trabajo intensivo con caracteres hubiera optado por un bus de datos de 8 bits, una memoria organizada en Bytes y registros internos también de 8 bits. Aquí me hubiera perdido la simetría dirección-dato; seguramente habría introducido los tradicionales "registros índices" de 16 bits para direccionamiento indirecto con lo cual mi computadora terminaría siendo un "Intel 8080" gigante.

Tal vez hubiese concebido operaciones de 16 bits en mi ALU con tal de manejar enteros eficientemente, por ejemplo, para acceso a arreglos en memoria. De esta manera podría proveer instrucciones eficientes tanto para enteros como para caracteres.

En cuanto a la aritmética BCD, la hubiera implementado por hardware. Una arquitectura de 8 bits me hubiese ahorrado casi la mitad del espacio y el costo de los circuitos, así que tendría espacio de sobra para construir un ALU contundente, capaz incluso de multiplicar y dividir.

El gran reto hubiese estado en codificar instrucciones en escasos 8 bits. En Heritage/1 todas las instrucciones se codifican en un solo word y el operando (si lo hay) es simpre de un word.

En una arquitectura de 8 bits, sigue siendo necesario leer operandos de 16 bits (por ejemplo, la dirección en una instrucción de direccionamiento directo) lo cual toma dos ciclos de máquina en lugar de uno. Una solución alternativa es acceder la memoria tanto en términos de bytes como words, es decir, alambrarla a 16 bits pero permitiendo que el CPU la acceda un word o un byte a la vez según la instrucción. Es una solución poco elegante, pero más eficiente.

Resumiendo, esta "máquina optimizada para sistema contable" (lo cual no le resta generalidad) sería muy diferente a Heritage/1. Su diseño no sería muy elegante pero seguramente abordaría su labor con mayor eficiencia.

Después de esta reflexión, el reto está en lograr que mi Heritage/1 consiga trabajar cómodamente con caracteres y una aritmética BCD implementada por Software, sin que para ello tenga que romper su arquitectura actual... [lo pensaré].