Heritage/1 homebrew Mini-Computer

Interactivo pero no inmediato

2010-08-22T01:26:00.017-04:00

Estoy tratando de imaginar una mini como Heritage/1 dedicada a una aplicación concreta (solo una) en un medio ambiente cooperativo como, por ejemplo, una pequeña empresa vendedora de componentes electrónicos.

Hay un equipo de vendedores (digamos, seis), cada uno en su buró, casi siempre respondiendo llamadas telefónicas y con un video terminal en frente. La minicomputadora está lejos de ellos, concretamente en el cuarto de Ingeniería.

El caso es que Heritage/1 no usa discos sino cintas magnéticas y estas son demasiado lentas para ofrecer una respuesta inmediata al usuario. La Heritage/1 que estoy imaginando corre un sistema operativo de tiempo compartido (Time-Sharing System) por lo que varios usuarios (en particular, estos seis vendedores) pueden acceder el sistema simultáneamente. Lo que no pueden hacer es obtener respuestas inmediatas y ellos lo saben. Veamos entonces cómo hacen.

Robualdo (vendedor) recibe una llamada de un viejo cliente, Juan Pérez, el cual le solicita un estimado para una nueva orden. Robualdo anota (en papel) los detalles y promete devolver la llamada lo antes posible.

Ahora Robualdo se dirige al terminal y lo utiliza para entrar una "solicitud". Esta consiste en llenar un formulario electrónico con el nombre del cliente en cuestión y los tipos de componentes así como algunas características de los mismos, de acuerdo con lo requerido. Sería algo así como esto:

CLIENTE: JUAN PEREZ
COMPONENTE: IC 74HC163
COMPONENTE: IC SOCKET DIP 16 PINS

Robualdo despacha la "solicitud" y se dedica a otros asuntos pues sabe por experiencia que la respuesta no tardará menos de 15 minutos en aparecer.

El sistema buscará el record de Juan Pérez en la cinta de CLIENTES para obtener la llave del record (client_id) y aprovechará la ocasión para copiar en memoria los restantes datos de ese cliente. Luego hará una consulta sobre la cinta de COMPONENTES trayendo a memoria los records que concuerden con los datos entrados en la "solicitud", a saber, todos los circuitos integrados tipo 74HC163 y todos los IC Sockets DIP de 16 pines. Una vez obtenida la información, el sistema preparará un informe y lo imprimirá usando una impresora compartida por los seis vendedores de la pequeña empresa.

Así que 15 minutos más tarde, Robualdo se dirige a la impresora y regresa a su buró con una larga lista impresa... ese es el resultado de su "solicitud".

De esta lista, Robualdo selecciona los componentes que mejor satisfacen las necesidades de su cliente y se dirige nuevamente al terminal para "entrar la orden". Ahora usará números de partes en lugar de descripciones para referirse a los componentes requeridos.

El punto es que el concepto de "solicitud" es intermedio entre "batch processing" y "time-sharing", o lo que es igual, entre los años sesentas y nuestros tiempos.

En los 60s, Robualdo no tendría un terminal en su buró sino un catálogo impreso, el cual fue producido por una impresora de línea ni siquiera propiedad de la empresa sino ubicada en un Centro de Cálculo que brinda ese tipo de servicio a esa y otras empresas. La orden sería llenada a mano sobre un formulario de papel. Una secretaria se encargaría de colectar las órdenes del día y las enviaría todas juntas al Centro de Cálculo para su procesamiento el cual incluye la trascripción de los formularios a soporte informático, posiblemente tarjeta perforada.

Así que la entrada de una "solicitud" en un video terminal ubicado encima de su buró constituye un gran avance para Robualdo. Esta simple acción reemplaza todo el movimiento de papales hacia (y desde) el Centro de Calculo, la transcripción en masa realizada por terceros, y la consecuente tardanza.

Es mejor esperar 15 minutos que todo un día para preparar una orden. El cliente estará satisfecho (y hasta admirado) de poder obtener respuesta en 15 minutos vía telefónica. Y la empresa estará más feliz aún al poder efectuar ventas con mayor prontitud.

Toda esta fantasía ha tenido un propósito: figurarme si un sistema de tiempo compartido basado solamente en cintas magnéticas, puede llegar a ser útil. Y veo que la respuesta es afirmativa pero solo si quito la "inmediatez" de la ecuación y concibo un flujo de trabajo acorde con la época que Heritage/1 representa.

¿Simulación a nivel circuital?

2010-08-15T17:42:00.001-04:00

Mi simultador (HSIM) está pensado para depurar software, no para probar los cirtuitos del naciente hardware; por eso la simulación está implementada a nivel funcional y no de compuertas, buses ni señales. No obstante HSIM me ha servido, como he comentado en mi articulo anterior, para modelar ciertas soluciones de hardware, mas ese —repito— no es su propósito.

De cualquier manera, este proyecto se encuentra ahora en una pausa hasta Septiembre, asi que he tenido oportunidad de pensar calmadamente sobre este y otros asuntos. La simulación de circuitos ha vuelto pués a rondar mi cabeza al ver que otros colegas lo han empleado con éxito en proyectos similares al mio.

Tengo dos referencias: Bill Buzbee's Magic-1 y Dawid's DIY. Ambos autores optaron (separadamente) por escribir un programa en C para representar los circuitos a nivel de compuertas y señales, y probar entonces la lógica del circuito en ese entorno soft.

No deja de ser una oferta tentadora porque el desarrollo de software es muchísimo más productivo que el de hardware. Pero aún asi, sigo temiendo que no funcionaría para mi. Las razones son estas:

1.- Simulación incompleta:

La simulación nunca llegaría a ser completa. No hace mucho, por ejemplo, tuve problemas con mis circuitos de "debouncing", los cuales detecté mientras probaba el circuito a golpe de switches. Estos problemas de naturaleza puramente eléctrica difícilmente podrían simularse en un programa escrito por mi.

Siendo asi, el propósito de ahorrame modificaciones de puesta a punto en un circuito cuyo diseño ha sido "certificado" por el simulador, queda automáticamente derrotado.

2.- Un proyecto de software complicado en si mismo:

Un simulador a nivel de compuertas no se escribe con simples "if~then~else". Es un proyecto complicado que hay que diseñar, codificar y depurar a lo largo de muchas semanas antes de que pueda servir para algo. Y aún después de terminado seguramente quedarán bugs que corregir... como en todo software.

Sospecho que ese mismo tiempo y esfuerzo se aprovechan mejor montando el circuito verdadero en un breadboard... y creo que optaré por esto último.

CONCLUSION

Conste que me he dado la oportunidad de considerar la alternativa del simulador circuital, avalado por su empleo en proyectos existosos como Magic-1. Pero una vez sacadas todas las cuentas, doy por cerrado el caso:

No probaré mis circuitos por software sino a la vieja usanza: en un breadboard. Y no tiene nada de extraño puesto que soy un hombre tradisional, tanto, que estoy construyendo una computadora de corte tradisional en este siglo XXI donde el respeto a las tradisiones tecnológicas suena casi como una palabra de mal gusto.

La experiencia del Simulador HSIM

2010-07-15T21:51:00.001-04:00

Hace poco más de un año comencé este proyecto, Heritage/1, y después de muchos tumbos he logrado acomodar una arquitectura estable basada en principios de diseño que dictan en definitiva qué exactamente he querido construir y cómo.

Mi incursión en el mundo de la simulación, sin embargo, es mucho más reciente, de apenas unas semanas; había leído antes sobre el tema en proyectos de otros colegas y nunca les había prestado la debida atención, específicamente por dos razones: (1) Quiero hacer una máquina corpórea, no virtual y (2) siempre me pareció que escribir un simulador podría ser tan complejo, consumidor de tiempo y presto a errores como el circuito mismo as simular... una pérdida de tiempo en definitiva —me decía entonces.

Pero sucedió algo: el diseño del hardware llegó a estar (casi) terminado y consecuentemente me sorprendo con un conocimiento profundo sobre cómo Heritage/1 funciona (... o funcionará). Vino entonces el deseo de comenzar a escribir software para ella, en particular su sistema operativo, el cual he dado en llamar H1OS y está(rá) orientado a Batch Processing usando cintas magnéticas como medio de almacenamiento, en lugar de discos. El problema es que la máquina aún no existe y, lo que es peor, falta mucho todavía —un año quizás— para que lo esté.

Entre tanto, las ideas sobre cómo levantar un sistema operativo, así como el deseo de hacerlo, han ido en aumento y es por eso que accedí a construirme esta "Heritage/1 virtual" o simulador llamado HSIM.

Escribir software es mucho más rápido que construir circuitos y es así que en menos de dos semanas de gestación, HSIM es ya capaz de ejecutar todas las instrucciones (cerca de 100) de Heritage/1. Una experiencia simpática es que, probando HSIM con programitas de prueba en lenguaje de máquina de Heritage/1, he encontrado más errores en esos programas que en el código del propio simulador.

No está terminado aún. Falta simular interrupciones de hardware, después de lo cual estaré en condiciones de simular los periféricos. Calculo que en dos o tres semanas más, HSIM v 1.0 podrá entrar en fase de producción.

Pero aún antes de nacer, este programita está generando experiencias. Mi idea para con él fue siempre la de no simular los circuitos a nivel de compuertas, sino solo el comportamiento de la máquina a nivel estructural. Había concebido, por ejemplo, la idea de leer el set de instrucciones desde un fichero en un arreglo, de modo que el primer paso para decodificar una instrucción sería encontrarla en el arreglo.

Es una solución "programática", contraria a mi modo de hacer las cosas pues yo tiendo a pensar más como ingeniero eléctrico que como programador. El primer tropiezo lo tuve en el gran número de instrucciones a procesar y el segundo, en el darme cuenta de que el concepto mismo se sale de "mi estilo".

Lo que hice entonces fue simular la manera en que los circuitos de Heritage/1 decodifican las instrucciones. Estos ven el código de operación (alojado en el registro de instrucciones IR) como un "bit-map". Los cuatros bits más significativos constituyen la "clase" en dependencia de la cual suceden dos cosas: (1) se realiza o no un Operand Fetch Cycle, y (2) se determina cual circuito se ocupará de decodificar y ejecutar la instrucción.

Esto a nivel circuital es bastante sencillo; es cuestión de alambrar convenientemente las diferentes (16) salidas del registro IR. En el caso del simulador es más fácil todavía: solo he tenido que dividir el código de la instrucción en diferentes campos y tomar decisiones en base a sus valores.

Esta manera de implementar en software una simulación más cercana al circuito (aunque sea a nivel de bloques, no de compuertas) me ha traído agradables sorpresas, como la de captar inconsistencias en el diseño del set de instrucciones y (por supuesto) corregirlas inmediatamente. También me ha permitido un mejor estudio de cómo manejar las banderas.

La experiencia global ha sido esta: el simulador, que en un principio concebí como una herramienta para depurar software, ha servido también como un "modelo" o "prototipo virtual" de la máquina, gracias al cual puedo ultimar detalles de diseño y aún encontrar errores en el diseño existente.

HSIM está escrito en Borlan Turbo Pascal 3.0 usando una vieja máquina Pentium corriendo MS-DOS 6.22 nativo. La máquina no usa "mouse"... sé que algunos se sorprenderán por esto.

La interfaz es extremadamente rudimentaria, hecha con puros caracteres ASCII de un solo color (verde sobre fondo negro). En realidad podría hacer algo más "fancy" pero ese sabor primitivo me recuerda mis viejos tiempos... la nostalgia se vale, ¿no?

El manejo es muy parecido al de Heritage/1. No he implementado (ni pienso hacerlo por ahora) facilidades típicas de "debuggers" como "watch", "break points" etc. Y es por una cuestión de concepto: HSIM no es un "debuger" sino un simulador, una versión virtual, de Heritage/1; y el propósito es que se le sienta como a aquella.

A este simulador seguirá un ensamblador (HASM) después de lo cual estará en condiciones de comenzar a escribir el entorno operativo de Heritage/1... antes de que la misma llegue a construirse.

Storage en Heritage/1

2010-06-15T02:00:00.000-04:00

Estoy decidido a utilizar cintas magnéticas "de verdad" (ni siquiera simuladas con diskettes... aquella idea del "V-TAPE") como audio-cassettes, open-reel 1/4 y VHS. Los discos (posiblemente floppies) vendrán después.

En un articulo previo titulado Uso de Storage en Heritage/1 expuse mis ideas sobre el uso de cintas en régimen de "Batch Processing" (ver tambien: Real Tapes). Pero ahora quiero explorar la naturaleza y el "sabor" del tape en si mismo dentro del contexto de este proyecto.

Hay un amplio espectro de aplicaciones cada una de las cuales tiene sus requerimientos propios en cuanto al uso de cintas magnéticas.

Una aplicación de base de datos, por ejemplo, requiere ficheros grandes y de longitud creciente; una operación frecuente será añadir records al final de la cinta (append) de ahi que no sea conveniente alojar más de un fichero en cada cinta. En tal caso el programa ni siquiera requiere la noción de "fichero": se contentará con tener un "drive" donde leer o verter datos en forma de "streams".

No sucede lo mismo con los programas, ya que estos son de longitud fija y por lo regular pequeña comparada con la capacidad de la cinta. Los programas han de residir pues en ficheros, habiendo varios (posiblemente muchos) de ellos en una sola cinta.

Un tercer caso lo constituyen los ficheros de configuración y programas de arrancada, ficheros pequeños y de uso aislado cuyo hábitat natural sería la cinta perforada... de ser esto posible para Heritage/1.

Los periféricos concretos que he concebido hasta ahora son los siquientes:

a) Video tape (VHS)
b) Audio 1/4 open-reel
c) Audio-Cassette

El VHS se presta mejor para bases de datos por su alta capacidad, mayor velocidad de acceso y (sobre todo) mejor disponibilidad, pues cualquier aplicación de bases de datos va a requerir de más un drive (cuatro como mínimo) operando simultáneamente.

La cinta open-reel me atrae por su sabor folklórico (recuerda las cintas utilizadas por las computadoras antiguas), pero su principal limitación radica en la disponibilidad... prácticamente solo podré contar con una de estas maquinas. Sin embargo, se presta muy bien para el oficio ya que su transporte puede ser controlado por programa y su capacidad y rendimiento son aceptables. Seguramente la utilizaré para albergar programas, incluido el propio sistema operativo.

El audio-cassette es tremendamente limitado tanto por su capacidad y velocidad de acceso (calculo que, fiablemente, unos 300 caracteres por segundo), así como la gran dificultad para controlar su transporte desde programa. Sin embargo, le tengo reservada una tarea honorable: reemplazar la tradicional cinta perforada de papel.

Una cinta perforada se coloca en el lector y se lee como un todo, de arriba a abajo. Esto lo diferencia de la cinta magnética a la cual se le reproduce, rebobina etc bajo el control del programa. Pues bien, eso mismo pienso hacer con el cassette: El programa se limita a leer o escribir el "todo" mientras el Operador (es decir, yo) maneja el mecanismo de transporte... manualmente. En este sentido, mi audio-cassettera simulará tanto al lector como a la perforadora de cinta.

Resumiendo, mi plan en cuanto al uso de cintas es el siguiente:

a) VHS: Database files
b) Open-Reel audio: Programas (incluido el OS)
c) Audio-Cassette: Bootsrap, config files, etc.

Y conste que nada de esto ha salido de la improvisación sino de muchas semanas dándole para atrás y para alante al asunto...

Un "Teletipo" para Heritage/1

2010-05-11T14:39:00.001-04:00

En la "era" de Heritage/1, un video-terminal como el legendario DEC VT100 podía considerarse un artículo de lujo (dado su costo). Lo más común como medio de comunicación usuario-computadora era el teletipo, de ahí el denominador TTY (teletype) usado por Unix para denotar los terminales.

Hasta ahora había pensado que Heritage/1 usaría, en calidad de terminales, PCs corriendo un emulador de terminal como KERMIT sobre plataforma MS-DOS; pero aún esta idea me parecía "demasiado moderna" (aún en calidad de emulación). Y es por eso que he comprado una máquina de escribir con el fin de convertirla en el "teletype" de Heritage/1... cuando llegue la ocasión, pues la computadora ni siquiera existe todavía.

Por supuesto, desempaqué el equipo, le enganché una hoja de papel y me puse a escribir... ¡la experiencia ha sido más que gratificante!

Con toda seguridad puedo decir que hace más de veinte años que no me sentaba a escribir sobre una máquina de estas; es radicalmente diferente a hacerlo en una computadora como las nuestras. El sonido de la impresión siguiendo inmediatamente el teclazo es como una melodía saliendo del piano (directamente de tus manos) y no del CD Player.

No tengo muy claro cómo voy a acoplar mi "teletype" a Heritage/1, es decir, cómo voy a modificarla para que ello sea posible. Seguramente comenzaré a experimentar con mi PC vía RS232, ya que a Heritage/1 le falta mucho para nacer. Mas por lo pronto he comprobado que la experiencia de comunicarse mediante un "teletype" (en lugar de un video-terminal) es única, algo que no se concibe hasta no haberlo experimentado con los propios dedos.

Resolviendo un cuello de botella (TESTING)

2010-04-23T17:57:00.000-04:00

En mi nota Desarrollo escalonado, hablé del cuello de botella que tengo con el asunto del "testing". A decir verdad, ya me había resignado a ello, pero en estos momentos estoy decidido a resolver ese problema de una vez por todas.

Bill Buzbee me ha aconsejado usar simulación por software, método este que él empleó con éxito durante el desarrollo de su Magic-1. Lo que él hizo fue escribir programas en C simulando directamente las funciones lógicas de los circuitos bajo prueba. Francamente, yo nunca he sido muy entusiasta de la simulación por software ya que —temo— la modelación misma del problema constituye un proyecto en sí, susceptible —como todo proyecto— de errores propios y consumidor —además— de muchísimo tiempo de desarrollo; no creo, pues, que la simulación pueda ser una vía fructífera para mi.

De modo que estoy hablando de probar mi electrónica... con electrónica. Y en realidad sí se puede, aunque no en la forma "completa" que había concebido hasta ahora; es decir, no una tarjeta a la vez sino "un circuito" (dentro de la tarjeta) a la vez.

Solo tengo que planear el orden en que voy a construir mis circuitos dentro de cada tarjeta de forma tal que pueda probarlos, uno a la vez, a punta de osciloscopio y suministrando estímulos estáticos mediante interruptores externos. Al menos podré testear, de esta forma, la lógica de mis circuitos.

También sería cómodo contar con un set de botones e interruptores "debounced" y un set de LEDs "buffereados". En realidad, en estos momentos ya puedo contar con el "LED DISPLAY" de la Consola, esto es: LEDs buffereados accesibles mediante conectores tipo "header". También puedo contar con botones e interruptores montados sobre el panel que solo están pendientes de alambrarse a otro conector tipo "header".

Me bastará pues construir cables (tipo cinta) "header to header" mapeados adecuadamente para cada test en particular.

Es una idea muy elemental que debió aparecer mucho antes en este proyecto... esa es la desventaja de trabajar solo: cuando te trabas en una mala idea, no puedes contar con otro cerebro que te destrabe.

Real Tapes

2010-04-11T21:40:00.000-04:00

Sigue siendo difícil para mi imaginar una minicomputadora de los 70s sin cintas magnéticas (tapes). Me he hecho a la idea de que mi Heritage/1 usará "virtual tapes" (V-TAPE), esto es, diskettes de 3.5 pulgadas sumulando tapes, y las razones son las siguientes: (1) Disponibilidad —aunque en vias de extinsión— (2) Presiento que con los diskettes uno establece la misma "relación afectiva" que con los tapes; (3) Capacidad y velocidad de acceso adecuados.

Pero (y a pesar de que Heritage/1 no ha nacido todavía), la idea de usar "cintas de verdad" no se aparte de mi cabeza. A menudo me siento a adelantar ideas sobre el diseño de software, especialmente system software y aplicaciones de gestión para una Heritage/1 trabajando en régimen Batch. Y siempre —indefectiblemente— pienso en cintas magnéticas con todas sus limitaciones, como la falta de direccionabilidad y la imposibilidad de insertar records en medio de la cinta. ¿Tendrían, estos problemas, el mismo sabor si los enfrento con diskettes, por más "virtual tapes" que estos sean?

La respuesta es un rotundo "no", y es por eso que me he lanzado a imaginar el uso práctico de tapes verdaderos como medio principal de storage en Heritage/1. Los diskettes pudiera usarlos también (más adelante) pero como discos, no como cintas.

El gran problema del "tape verdadero" está en la disponibilidad, especilamente porque, para correr aplicaciones útiles, voy a necesitar más de una (digamos, ocho). Y es justamente con esas miras que he tornado mi atención a las máquinas video-casseteras VHS.

De cara al proyecto, estas máquinas presentan las siguientes ventajas:

1.- Son extremadamente baratas en estos días por encontrarse en fase de extinsión.
2.- Su mecanismo de transporte es inherentemente controlable electrónicamente.
3.- Mayor ancho de banda que una grabadora de audio y, consecuentemente, menor tiempo de acceso al dato.
4.- El cassette de VHS puede llegar a ser tan "afectuoso" como el diskette o el mismísimo tape.

Utilizazar una cassetera VHS como storage es un proyecto en sí, mas no he querido esperar a tener lista Heritage/1 sino acometerlo de inmediato (paralalamente) con vistas a accederlo desde mi PC Linux durante su desarrollo.

Se trata de un experimiento, no de un producto. El objetivo es ir desarrollando técnicas que me permitan fabricarle un storage decente a Heritage/1 llegado su momento. El proyecto es interesante en sí mismo por involucrar muchos tópicos como estos:

- Codificación bifásica (en la cinta). Y su decodificación, claro está.

- Uso de PLLs (para el propósito anterior).

- Corrección de errores (CRC). Sin esto es imposible trabajar con medios magnéticos.

- Gobierno del transporte (aunque ello será muy fácil dado que la mayor parte ya está hecho en la propia máquina).

- Comunicación serie (RS-232) desde Linux con un dispositivo externo (el tape drive, en este caso).

- Desarrollo de "device drivers" para Heritage/1 (inicialmente escritos como aplicaciones PHP or C en mi Linux PC).

- Un largo etcétera.

A la postre no será ocioso tener acceso a VHS tapes desde mi Linux PC ya que ello puede constituir un puente para el intercambio de información. Por ejemplo, los programas para Heritage/1 serán elaborados usando mi PC; de modo poder guardar el código resultante en tape directamente desde mi PC (para luego cargarlos de tape a Heritage/1) será una buena cosa.

Heritage/1 en un Centro de Cálculo

2010-04-04T02:46:00.001-04:00

Es difícil para el hombre moderno imaginar el uso de computadoras sin interactividad... y conste que por "moderno" me refiero a los tiempos de Unix, es decir, principios de los 70s. Interesante notar, sin embargo, que por las dos décadas que precedieron la tal "modernidad", las computadoras se utilizaron exclusivamente de manera impersonal sin rastro de interactividad con el usuario; es más, el concepto de "usuario" —como lo entendemos hoy— ni siquiera existía.

Conceptualmente, Heritage/1 es una máquina de aquella época de transición entre el "batch" y el "time-sharing", y es por ello que pretendo utilizarla inicialmente como se usaban aquellos enormes armatostes en los llamados Centros de Cálculo. He de confesar que ha requerido un gran esfuerzo de abstracción por mi parte pues yo también estoy contaminado con la experiencia interactiva (por no decir, "hiperactiva") del PC moderno.

El primer desarraigo a conseguir en este empeño es, pues, el despego al uso interactivo de la computadora. Una Heritage/1 operando en un Centro de Cálculo no se accede de forma interactiva sino se le cargan "jobs", se le entran "tapes" (V-TAPEs) con datos y se obtienen resultados impresos por la impresora.

A lo anterior sigue la retro-definición del concepto de usuario. Heritage/1 puede servir, en efecto, a un gran número de usuarios, solo que estos nunca acceden directamente a la máquina y muy posiblemente ni siquiera lleguen a verla en ningún momento; en cambio, se limitarán a suministrar datos recogidos en formularios y recibir resultados impresos por Heritage/1 los cuales les llegarán seguramente por medio de un mensajero de carne y hueso.

Los encargados de operar directamente la computadora son "operadores" profesionales. Por esta razón, Heritage/1 no posee más que un video-terminal —o un teletipo, quizás— y su sistema operativo no implementa el concepto de usuario en lo absoluto.

Valga aclarar que en la terminología de Heritage/1, a este sistema operativo se le llama "Monitor", ya que en una fase ulterior de desarrollo se escribirá un "time-sharing system" (multi-usuario) para el cual he reservado dicho término.

Muy similar al descrito anteriormente era el modus operandi de toda máquina computadora antes de los 70s. De más está decir que, dado su inmenso costo, las mismas acarreaban trabajos voluminosos como nóminas e impresión de cheques de pago para toda una compañía. Ello contrasta con el uso que podré darle en la práctica a Heritage/1, pero el punto es no perder la perspectiva histórica referida, en este caso, a los tiempos de "batch procesing".

Un detalle interesante en este punto está en la entrada de datos. En aquellos tiempos, los datos solían entrarse por tarjetas perforadas o cintas magnéticas previamente preparadas mediante equipamiento externo a la computadora.

En el caso de Heritage/1 no usaré tarjetas perforadas ¡por supuesto! sino V-TAPES (diskettes simulando cinta magnética). El problema está en dónde preparar dichas entradas... ¿en un PC? —Sería tolerable como simulación pero no constituye una práctica del todo "legal".

La solución (consecuente con el contexto histórico observado) proviene del hecho de tratarse de una "minicomputadora" y no un gran "mainframe". Una mini se diseña para operar en una pequeña empresa y su razón de existir radica en su "bajo costo" (comparado con el de un mainframe). La necesidad de adquirir equipamiento externo para la preparación de entradas (como perforadoras de tarjetas) constituye, pues, una tremenda limitación en el empeño de reducir costos.

He aquí una solución que hasta pudiera constituir una estrategia de mercadeo si Heritage/1 fuese una máquina comercial de la vida real: El Monitor ofrece utilidades para preparar entradas utilizando la computadora directamente, lo cual elimina la necesidad de adquirir equipamiento externo.

En efecto, este Monitor no opera en régimen multi-usuario pero si, en modo multi-tarea, es decir, puede correr varios procesos simultáneamente (multiplexados en tiempo). Siendo así, la utilidad para la preparación de ficheros de entrada puede correr simultáneamente con el "job" en curso.

Nótese que lo anterior NO implica interactividad. Preparar entradas implica única y exclusivamente, edición de ficheros en V-TAPE, lo mismo que hubiéramos hecho usando equipamiento externo.

Otro aspecto interesante de una Heritage/1 trabajando en modo batch está en su uso. Contrario a la asignación específica que tendría un time-sharing system (por ejemplo, sirviendo el catalogo en una biblioteca pública), en un Centro de Cálculo, Heritage/1 podría asimilar todo tipo de labor. Ello se debe a que el software es siempre algo externo y eventual cargado desde un medio desmontable como una cinta magnética (V-TAPE en este caso), lo mismo que los datos de entrada, lo cual contrasta con la percepción moderna de "todo en mi PC" recidiendo de forma permanente.

En base al modus operandi aquí descrito, habré de diseñar las aplicaciones para Heritage/1 mientras la misma opere en modo batch exclusivamente. Y he de confezar que me resulta en extremo interesante, especialmente por permitirme pensar la computadora de una manera muy diferente a como la pensamos hoy.

Desarrollo Escalonado

2010-04-03T16:35:00.001-04:00

Todo proyecto técnico se desarrolla en ciclos 'diseño, prueba, refinamiento del diseño' que se repiten escalonadamente hasta lograr los objetivos planteados. Y digo "escalonadamente" porque un proyecto técnico suele constar de varios componentes dependientes los unos de los otros, de modo que habrá que poner a punto unos antes de diseñar aquellos otros que dependen de ellos.

Heritage/1 es un proyecto particularmente complejo en cuanto a que (1) comprende un gran número de componentes y (2) las interdependencias entre ellos es bastante intrincada. Es por ello que me ha sido difícil arribar a la deseada "fase de desarrollo escalonado", encontrándome pues atrapado en una fase donde abundan los dibujos pero casi nada ha sido construido y mucho menos, probado.

El diseño, sin embargo, puede considerarse definitivo aunque solo en términos generales. Ello comprende (entre otros) lo siguiente:

- Arquitectura de la máquina en general y del CPU en particular, incluyendo detalles como dotación de registros y buses así como una filosofía bien definida de funcionamiento que incluye mecanismos de interrupción y arbitraje.

- CPU Backplane pinout, lo cual comprende el diseño detallado de los buses internos y la asignación de tarjetas a conectar directamente al Backplane.

- Diseño detallado de la interconexión entre el Backplane y los otros componentes del CPU como la Consola, los Buses Externos y la fuente de alimentación.

- Diseño detallado de los buses externos.

- Diseño completo de la Consola, compuesta esta por cuatro tarjetas además de los botones, interruptores y lámparas (LEDs) de mando.

- Diseño completo de la tarjeta H11R-GEN que contiene dos registros generales (BC ó DE).

- Diseño parcial de otros circuitos como el Master Controller (tarjeta H11C-MC).

- Esbozo del resto de los circuitos como el ALU, A, PC, SP, decodifucadores de instrucciones (tarjetas IDS) y otros.

- Esbozo de técnicas para entrada salida y software de sistema.

Lo ideal hubiera sido construir estos circuitos uno por uno, probarlos (y refinarlos) por separado; luego conectarlos entre sí y probar su funcionamiento conjunto. El problema es que ninguno de estos circuitos puede trabajar independientemente; en particular, ninguno de ellos puede trabajar sin la existencia del Backplane y la Consola. Es por ello que he puesto la prioridad en producir tanto el Backplane como las cuatro tarjetas que componen la Consola. En el momento de escribir estas líneas me encuentro de lleno en esa tarea.

El problema de este desarrollo "no escalonado" está la ineficiencia. Alambrar el Backplane tomará (según estimo) cerca de un mes; construir las tarjetas tomará una semana por cada una, de modo que construir esta "infraestructura" tomará por lo menos dos meses (seguramente mucho más dado que no dispongo de mucho tiempo libre) y solo después estaré en disposición de comenzar a probarlo... ¡todo de conjunto!

Mi pronóstico para las primeras pruebas no puede ser otro que "total desastre", así que me tomará al menos otros dos meses lograr que todo eso llegue a funcionar correctamente.

Una vez vencida esta difícil etapa, es decir, una vez puesta a punto la infraestructura del CPU, podré entonces pasar a la ansiada fase de "desarrollo escalonado".

Ya veis que difícilmente esto podrá ocurrir antes de Agosto del presente año. Una Heritage/1 completamente funcional no estará pues disponible antes Enero del año 2011.

Auto-entrevista

2010-02-27T22:26:00.001-05:00

¿COMO DESCRIBES A HERITAGE/1 (EN POCAS PALABRAS)?

Una minicomputadora del siglo XX fabricada caseramente en el siglo XXI diseñada para realizar trabajo útil a la usanza de aquellos tiempos.

¿EN QUE BASASTE LA ELECCION DEL CONTEXTO HISTORICO?

No fue una dedición repentina; se fue gestando naturalmente a lo largo de los dos primeros meses.

Quería construir mi máquina con circuitos integrados de la serie 7400, así que debería ubicarla después de 1966, año en que los mismos fueron inventados. Pero por aquellos tiempos, las computadoras empleaban memoria de ferrita —¡imposible para mi!— de ahí la segunda cota en 1972, año en que Intel hizo un lanzamiento masivo de su primera memoria semiconductora (1103).

En 1972, sin embargo, las "minis" ya no eran tan simples como pretendía ser mi Heritage/1. Ya empleaban memoria virtual, discos duros y hasta microprocesadores en labores de apoyo (como en sus terminales). Resolví pues imaginar una máquina diseñada en 1966 con memoria de ferrita, la cual fue reemplazada más tarde con memoria semiconductora una vez que esta estuvo disponible (1972).

En mi favor juega el diseño modular de Heritage/1. En efecto, la memoria está ubicada en una unidad dedicada, separada del CPU, enlazada a este por un bus propietario que consiste en dos cables tipo cinta. De modo que, en la vida real, no hubiera sido difícil reemplazar la vieja memoria de ferrita por semiconductora.

Advierto que he sido estricto con este contexto histórico (1966-1972) pero solo hasta donde ha sido razonable hacerlo. Por ejemplo, mi memoria no es Intel 1103 (Dynamic 1Kx1), sino 6264LP-70 (SRAM 8Kx8 70ns). Así mismo, mis chips no son TTL sino sus equivalentes HCMOS pues los primeros consumen demasiada energía y se calientan mucho.

Tampoco usaré cintas magnéticas sino diskettes, aunque "pensados" como cintas. Y tampoco tendré terminales de teletipo sino PCs corriendo Kermit sobre MS-DOS.

¿UNA MAQUINA "UTIL" O UNA MAQUINA "EN USO"?

Una premisa es que sea útil, lo cual constituye una guía para el diseño mismo: se trata de producir una minicomputadora, no un experimento; muchas dediciones de diseño se han basado en esa premisa.

Mi sueño —¡aparte de que realmente funcione!— es utilizarla en labores de mi día-a-día. No creo que le confíe mi sistema informático personal, pero tal vez le encargue algunos trabajillos simples como cálculos matemáticos y labores de control. Esto último resultará más sencillo en un hardware simple y bien conocido como el de Heritage/1 que en un PC donde, entre el hardware y el software de aplicación, hay todo un abismo.

¿QUE SISTEMA OPERATIVO USARA HERITAGE/1?

No lo sé todavía. Ahora estoy enfocado enteramente en el diseño del hardware. ¿Un hardware optimizado para un cierto sistema operativo? No, en realidad, no, y esto forma parte de la "cultura" de Heritage/1.

El único interés del hardware, en general, es brindar apoyo a un software cada vez más demandante. La verdadera acción está en el software; esto es una realidad que existe desde hace décadas. Heritage/1, sin embargo, se ubica en un contexto histórico donde el hardware todavía era motivo de interés para los propios programadores.

Asi que este proyecto constituye, digamos, la oportunidad de saborear el diseño de una computadora vista como artefacto electrónico (solo hardware)... el software vendrá después. Y —con suerte— asombrarse luego de que algo tan intrincado como un sistema operativo pueda correr en ese engendro que no fue diseñado expresamente para él.

Pero sí, Heritage/1 correrá algún sistema operativo a la postre. Mi sueño (a largo plazo) es poder portar un Unix clone como Minix o netBSD; mas no puedo garantizarlo ya que los sueños, sueños son...

¿ALGO MAS QUE SOÑAR?

Yo creo que todo proyecto de hobby sirve como inspiración canalizadora de conocimiento práctico y Heritage/1 no es una excepción. A fin de cuentas el conocimiento (en general) es abstracción y como tal, un sueño.

El de Heritage/1, en particular, ha coseguido exponerme a un caudal de conocimientos del que apenas tenía noticias y muy vagas. El solo deseo de correr Unix en Heritage/1, por ejemplo, me ha llevado a explorar esa cultura (Unix es una cultura, más que un sistema operativo) al punto de instalar netBSD en un viejo PC y ponerme a jugar con él.

Otro de mis sueños es que esta experiencia sirva, no solo para mi. No estoy enfocado a ello, pero me gustaría que la documentación de este proyecto sirviera a la postre para beneficio de hobistas y estudiantes, de la misma manera en que yo me he servido de otros (anteriores a mi) como Bill Buzbee's Magic-1 y John Doran's D16/M (ver enlaces).

¿Ficheros del sistema en V-TAPES?

2010-02-26T03:40:00.001-05:00

Ya he dicho que Heritage/1 no usará discos fijos (hard drives), al menos duarnte su infancia. El tipo de storage a que me he enfocado mentalmente es el "V-TAPE", esto es, un diskette simulando el comportamentiendo de una cinta magnética de los viejos tiempos.

He visto recientemente que en realidad no tengo que escribir un file system para ello sin tan solo formatear mis diskettes en bajo nivel para usarlos como "raw floppies", un concepto que se utiliza en la vida real de nuestros días.

Pero el punto que me ocupa es otro: ¿Cómo se las arregla el OS para manejar ficheros de configuración alojados en medios tan lentos? Dicho sea de paso, sigo tentado a utilizar una "open reel" de audio como storage también.

El caso es que un sistema operativo tipico como Unix se basa en muchos ficheros de configuración —asi como shell scripts— para funcionar. ¿No sería entonces demasiado costoso —en términos de tiempo— hacer constantes lecturas de ficheros en cinta o en V-TAPE? Por otra parte ¿de cuantas cintas y V-TAPES voy a tener que disponer solo para el uso exclusivo del OS?

Creo que la respuesta está en mantener esos ficheros cargados en memoria todo el tiempo, o al menos mientras haya memoria disponible para las aplicaciones. Esto, en general, me lleva a un mecanismo de CACHE que no solo involucra a los ficheros del sistema sino a todos en general.

Esto del CACHE siempre es interesante a la vez que intrincado. El sistema debe retener la imagen de los ficheros y decidir prioridades a la hora de desalojarlos de memoria en favor de otro fichero más urgente de ser cargado (por ejemplo, un programa). Y esas prioridades deben estar indicadas en alguna parte... por ejemplo ¡un fichero de configuración!

Otro camino (paralelo) es aumentar la eficiencia del acceso a storage. Por ejemplo, proveer de algún medio para que mi "open reel" puede encontrar ficheros rapidamente en el tape que tiene montado. Se me ocurre, por ejemplo, que la máquina cuente las rotaciones del motor 'take' y en base a ello provea "direcciones aproximadas" de los ficheros contenidos en la cinta. La máquina rebobinaría a alga velocidad, pero contando vueltas, de modo que cuando considere estar cerca de la meta, prosiga la búsqueda a velocidad nominal.

Para ello, el controlador de la máquina debe poseer una memoria interna (no en el mapa de memoria) donde guardar una especie de directorio, el cual fue leido de la propia cinta at "mount-time".

El mismo problema (y quizas en mayor grado) se presenta con mi Run-Time Library (RTL), el cual debe estar disponible para diferentes programas, pero al mismo tiempo ocupa un lugar considerable en memoria.

Lo interesante de todo esto es explorar cómo esas labores que nuestros sistemas operativos modernos resuelven "fácilmente" gracias a la tenencia de un disco enorme, se pueden resolver en un medio donde el estorage es escaso, lento y de poca capacidad... ¿Cómo lo hacían en los 60s... de eso justamente se trata.

Manuales Técnicos

2010-02-12T05:14:00.001-05:00

Según el propio Dennis Ritchie, el Manual de UNIX nació como un proyecto de documentación muy serio. Tanto empeño fue tomado en su elegancia que a menudo el código a documentar se corregía con tal de que "luciera bien" en las páginas del Manual.

Desde entonces, todo sistema UNIX (o clone) viene equipado con un sistema de ayuda electrónico llamado "Man Pages", cuya estructura respeta aquella del manual original de 1972. Y no solo la estructura sino además una buena parte de su contenido, como la del olvidado comando DC (Desktop Calculator).

El hecho de que un Manual sirva el doble propósito de documentar lo hecho y guiar lo que está por hacer, me ha parecido una idea digna se adoptar y es asi como he agregado al site oficial de Heritage/1 una serie de "libros" llamados respectivamente: "Operator's Manual", "Engineer's Manual" y "Programmer's Manual".

En estos días he dedicado gran tiempo a estructurar y generar contenido para el Engineer's Manual. No estoy seguro de que alguien lo leerá, pero como documentación seria del proyecto y como referencia para mi mismo, se presta muy bien, según estoy viendo.

Una Comunidad sin Propiedad Privada

2010-01-24T06:16:00.001-05:00

No es fácil desembarazarse de la imagen del "usuario feudal": ese sujeto que muestra credenciales a las puertas de la muralla, y una vez en sus dominios, dispone de ellos como dueño y señor. Sin embargo... cabe concebirlo de otra manera.

SESSION no implica directamente USUARIO

Para un sistema al que pueden acceder varias personas a la vez surge la necesidad del concepto de "session".

Una SESSION representa una "jornada de trabajo" vista desde la perspectiva de quien está utilizando el sistema via Terminal. En un momento dado, N personas estarán conectadas a N terminales y para ello han de existir N sessiones separadas, una por cada uno. Si, en particular, todos están haciendo uso del mismo programa, existirán entonces N instancias del mismo programa lo cual implica N areas de datos separadas: una por cada instancia, es decir, una por cada session, o lo que es igual, una por cada visitante.

Nótese que he dicho "visitante", no "usuario"; esto es porque la necesidad de definir usuarios no emana directamente del concepto de SESSION sino del concepto de "propiedad privada" (de esos usuarios sobre ciertos medios del sistema, como por ejemplo archivos). Desde la perspectiva del OS, los usuarios son entidades registradas con anterioridad en estructuras de datos diseñadas al efecto. En presencia de "propiedad privada", cada SESSION se hará pertenecer a un usuario (previamente registrado) el cual tendrá que identificarse (decir quién es) antes de poder ganar acceso a sus propios recursos.

Otra posibilidad es renunciar a la "propiedad privada". En tal caso, todos los recursos del sistema serán patrimonio de todo aquel que lo visite y entonces el concepto de usuario perderá automáticamente su sentido.

El concepto de SESSION, sin embargo, prevalce, pues sigue siendo necesario que varias personas laboren con el sistema al mismo tiempo sin que sus acciones se interfieran mutuamente.

Imagine all the people sharing all the World

La experiencia de un sistema compartido sin privilegios entre todos sus visitantes la tenemos hoy en la Internet (Wikipedia es un buen ejemplo), pero trataré de imaginar un sistema como Heritage/1 en 1972.

Digamos que una minicomputadora Heritage/1 está instalada en una compañía productora de Software. Hay ocho programadores cada cual con su correspondiente terminal. Todos los recursos de la máquina (especialmente los perifericos: cintas, impersoras etc) son compartidos de modo que algun arbitrage deberá ejercer el OS para evitar que, por ejemplo, una impresión salga con prociones entrelazadas de dos programadores diferentes.

Dicho arbitraje, sin embargo, no implica relaciones de propiedad sobre los recursos sino tan solo un mecanismo para poner orden dentro del libertinaje. Por ejemplo, si dos procesos han solicitado el uso de la impresora, entonces uno de ellos tendrá que esperar hasta que el otro termine.

Sin llegar a la Anarquía

Ahora coloquemas una Heritage/1 en una biblioteca pública. El Catálogo de la biblioteca recide en una base de datos accesible a los visitantes por medio de cuatro terminales instaladas en el salón. El visitante no tiene que identificarse, simplemente consultar el Catálogo directamente desde cualquiera de los terminales; y no solo realiza operaciones de lectura sino, además, deja comentarios, sugiere libros no presentes en el catálogo, etc, siempre de manera "anónima" (desde la perspectiva del sistema) lo cual no impide que alguien deje su nombre y numero de telefono voluntariamente.

La actualización del Catalogo, sin embargo, no puede dejarse en manos de los visitantes ya que esta es una tarea profesional; de modo que el sistema ofrece unos programas para los visitantes y otros para los bibliotecarios.

Esto puede resolverse en base al Terminal (puerto), es decir, sin necesidad de crear usurios. El OS puede puede crear una tabla de programas disponibles y por cada uno de los cuales se especifican los terminales (puertos) autorizados a servirles de interface. De esta manera, los visitantes nunca ganarán acceso a los programas de mantenimiento del Catalogo.

¿Cómo se relaciona esto con la SESSION?

Cuando el visitante entra al sistema a través de un Terminal, se le crea una session atada a ese terminal; el shell le presenta una lista de programas disponibles para "él" (en realidad, para ese puerto). Aparte del Catalogo pudieran haber otros programas como utilitarios matemáticos; el usuario pude correr esos programas, obtener sus resultados, enviarlos a la impresora (compartida con otros, tal vez tenga que hacer cola) y luego cerrar la session, o no.

Los terminales utilizados por los bibliotecarios operarán de manera similar, solo que estos tendrán acceso tanto al Catálogo como a los programas de Mantenimiento del mismo.

¿Y cual es la ventaja de todo esto?

La ventaja es no tener que manejar usuarios dentro del OS, lo cual representa un tremendo ahorro de esfuerzo en cuanto a desarrollo y mantenimiento del sistema.

Ya hemos visto que un sistema asi puede encontrar cabida en un entorno cooperativo de trabajo como desarrollo de software y en un servicio público con el de una Biblioteca. En general encontrará cabida en una instalación donde la computadora ofrezca servicios especificos a una audiencia específica, como era común hasta principios de los 80s.

Hoy en día, ese tipo de servicio (propósito específico, visitantes no privilegiados) sigue siendo común, especialmente en la Web. Solo que a nivel de implementación sí se utiliza el concepto de usuario por razones de seguridad y —sobre todo— porque los sistemas operativos empleados lo tienen implícito.

CONCLUSIONES

En un sistema de tiempo compartido necesitamos el concepto de SESSION para construir un "entorno de trabajo" separado para cada terminal. El concepto de USUARIO, sin embargo, es opcional.

Si no se requiere "propiedad privada" (de usuarios sobre recursos), el concepto de USUARIO está de más. Implementarlo solo consiguiría sobrecargar imnecesariamente la complejidad del sistema.

Si se requiere privacidad del Administrador sobre ciertos recursos del sistema (ejemplo: programas de mantenimiento y ficheros de configuración), no es necesario ver al Administrador como un "usuario": basta restringuir dichos recursos a aquellas terminales destinadas al Adminstrador.

Un recuento de experiencias

2010-01-24T04:54:00.000-05:00

Aún cuando Heritage/1 solo existe en el papel y a medias (aunque ya estoy construyendo los primeros circuitos), su diseño ya cuenta como una experiencia personal de la que he sacado algunas enseñanzas.

PANEL DE CONTROL

No podía imaginarme una minicomputadora de los 70s sin un panel control repleto de interruptores y lámparas majable a nivel de bit. Sin embargo, el diseño de este panel y —sobre todo— su conexión al resto del circuito han presentado tantas dificultades que hasta llegué a pensar en suprimirlo del todo.

A decir verdad, mi panel es mucho más simple que el de otras "home-brew" minis que he estado estudiado (ver enlaces), pero aún asi resulta recargado si se le compara con verdaderas minicomputadoras de los 70s como la DEC PDP-11. La dificultad del panel se presenta en dos frentes: (1) requiere un gran número de conexiones con el CPU, y (2) no puede ser "inteligente" puesto que es el primer sitio a mirar en caso de fallas por lo que debe ser absolutamente confiable.

Los problemas los he ido resolviendo poco a poco a expensas de simplificarlo cada vez más. Finalmente he podido llegar a un diseño definitivo con el cual estoy satisfecho, no asi con la gran cantidad de tiempo que he tenido que dedicarle.

Como enseñanza me queda que un panel de control ha de ser lo más pequeño y simple posible con apenas lo indispensable para operar la máquina, tal vez no tanto para ayudar a la puesta a punto de programas. No he querido seguir simplificando mi diseño actual porque, definitivamente, quiero tener la experiencia de operarlo con todos sus interruptores y lámparas. Quiero aprender de la práctica cuales de sus recursos son útiles y cuales, no.

UNA MAQUINA DE PROPOSITO GENERAL

Me propuse diseñar una máquina simple orientada a enfrentar cualquier tipo de labor... que es lo mismo que decir: ninguna labor en concreto. En mi articulo Ocho bits versus dieciséis exploraba la idea de un diseño optimizado como alternativa al diseño generalista que Heritage/1 defintivamente tomó; por ejemplo, Heritage/1 no optimiza el tratamiento de caracteres ni brida apoyo para un sistema operativo de multitarea preventiva con protección de procesos.

La moraleja es que "propósito general" en realidad significa: "gran número de propósitos específicos". Si alguna vez vuelvo a enfrentar este reto, aplicaré esta enseñanza para orientar el diseño a ciertos "algos"; mi esfuerzo estará dirigido entonces a optimizar para cada uno de ellos.

ARQUITECTURA DE HARDWARE VS. SOFTWARE DE SISTEMA

Uno de los propósitos de este proyecto ha sido el proveerme un entorno "entendible" donde poder jugar a mis anchas con el diseño (u adopción) de software de sistema. Si bien la arquitectura de computadoras ha resultado apacionante para mi, mucho más lo está siendo la programación de sistemas operativos... solo que en esto no podré incursionar hasta tanto el hardware no esté listo.

Una alternativa hubiera sido diseñar un hardware factible de ser armado en poco tiempo, por ejemplo usando un microprocesador de la generación de los 80s como Intel 8085 o Zilog Z80; el aspecto cultural se hubiera satisfecho con tan solo "correr el contexto histórico" hacia esa década. Solo que entonces me hubiera perdido el "sabor" de una máquina sin misterios, sin "boot up" y sin LSI, todo aquello que a fin de cuentas forma parte de la personalidad y la cultura de Heritage/1.

DEFINITIVAMENTE UN "MAIN-FRAME"

Los 80s trajeron el concepto de "computadora personal": una máquina cuyo bajo costo justifica su uso dedicado a una sola persona. Hoy en dia la computadora no solo ha salido del Centro de Calculo hacia el buró, sino también de este ¡al bolsillo del propietario! —En efecto, un teléfono celular de nuestros días es más potente que un mainframe de mediados de los 60s como la IBM System/360.

La percepción actual (tanto doméstica como industrial) es que una computadora ha de tener una tarjeta de video, una interfaz gráfica y un ratón. Heritage/1 es portadora de la visión lejendaria, definitivamente opuesta: Una computara solo "computa"; a ella se le accede mediante "terminales" externos; ella, de por si, no proporciona ninguna via para ser "mirada" ni "comandada" directamente por sus usuarios.

Una versión moderna de Heritage/1 reemplazaría sus puertos serie (a donde se conectan los terminales) por una conexión Ethernet, correría UNIX y figuraría como un "host" dentro de una red TCP/IP. Los "terminales" serían entonces computadoras de escritorio como Macs o PCs; o tal vez se fabricarían terminales propietarias capaces de presentar una interfaz gráfica, tal vez Web.

Pero siempre sería, Heritage/1, un máquina centralista: un "mainframe"; no proveería ningún medio que permitiese tratarla como a una vulgar computadora de escritorio.

En este sentido se parecería más bien a una IBM AS/400. Mi enseñanza en este sentido es que el mundo de los PCs no me resulta atractivo en lo absoluto.

La verdadera motivación del proyecto

2010-01-09T05:10:00.001-05:00

Heritage/1 es un proyecto cuya necesidad no es fácil de explicar en términos rotundos y convincentes (en eso se parece al vicio de fumar), pero el esfuerzo de diseñar, construir y programar una computadora prehistórica, concebida además para realizar trabajo tangiblemente "útil", ¡exige una explicación!

A decir verdad, explicaciones he dado, como aquella de "saborear los problemas del pasado", y "honrar una herencia tecnológica". Pero si de tocar la historia con las manos se tratase ¿no sería más apropiado clonar un dinosaurio de aquellos, como hizo Jhon Pultorak al replicar el Apollo Guidance Computer en el sótano de su casa?

En este punto he de confesar que mi motivación real (subyacente), sin dejar de ser una de índole técnico-cultural, está más bien en mi deseo de producir una computadora que se pueda entender, contrario a esta "caja negra" sobre la cual escribo estas notas.

Recuerdo que mi primer "contacto afectivo" con la programación fue en 1982, fecha en que descubrí los microprocesadores de ocho bits, en particular el Intel 8085. Y mi mayor gozo provenía justamente de que aquello ¡se podía entender! —Un microprocesador 8085 no deja de ser una "caja negra", pero dentro del nivel de abstracción que su diagrama en bloques proporciona, uno puede trabajar confiado como se hace en un bote navegando en aguas poco profundas. No sucede lo mismo con un PC.

Crear una computadora que "se entenda" ha sido pues el principal objetivo de Heritage/1, de ahi la póliza de sencillez en su diseño. Su capacidad para "realizar trabajo útil" ha sido otra premisa, aparentemente en contradicción con la primera pues un hardware "sencillo" difícilmente podrá brindar frutos si no es a expensas de un software muy complejo.

Lo cierto es que en seis meses, y aún con un diseño a medio terminar, he llegado a aprender con relativa profundidad una infinidad de tópicos sobre los cuales tenía tan solo una vaguísima idea. Ha sido como llegar a tierras desconocidas, haberme dado a la tarea de dibujar sus mapas y, gracias a ellos, experimentar a la postre una tremenda familiaridad con el paisaje.

En ese sentido, Heritage/1 ha sido —está siendo— una experiencia única. Y creo que en la aparente vaguedad de su propósito, reside, paradójicamente, su principal riqueza: la cultura, ese componente que no admite formulación matemática alguna.

La tecnología, así como las matemáticas, resultarán frías y aburridas mientras no adquieran rasgos culturales propios: tradición, ética, estética, todo aquello que permite al diseñador intimar con su diseño en términos humanos, es decir, con pasión y gozo. Y es así como una carpeta de dibujos, un prototipo y una idea —Heritage/1— han llegado a conformar un ente cálidamente vivo con quien suelo conversar... íntimamente; y es esa necesidad de "intimar" lo que exige de ella sencillez y comprensibilidad. Una experiencia única —apuntaba— pero solo en lo personal pues la tecnología toda está llena de tradiciones; hay consenso en qué es un "diseño elegante" y qué, uno "macarrónico, aún cuando no existen fórmulas para calcular la elegancia ni la macarronicidad.

Heritage/1 tiene pues su cultura propia: Una historia que contar, una tradición que seguir, un criterio ante el espejo. Podrá llegar a funcionar o no, hacerlo bien o hacerlo mal, pero en cualquiera de esos casos el criterio para evaluar su éxito no estará en los MIPS (millones de instrucciones por segundo) sino en su aporte a una tradición tecnológica a la cual ha querido sumarse como un eco desde estos tiempos en que las computadoras son veloces, pero no románticas.

Personalidad

2010-01-01T03:30:00.000-05:00

La esencia de Heritage/1 está en su personalidad. Rústica, comedida y simplona, laboriosa y ávida de retos pero poco dispuesta a cambiar su anatomía y su modo de enfrentar la vida. El contexto histórico (1966-1972) a que le he restringido es —quizás— tan solo un pretexto para no contaminar esa esencia con el sofisma exagerado de nuestro tiempo. Heritage/1 tiene una personalidad que justifica su nombre y su sentido de ser, y es justo eso lo que la convierte en un proyecto con el cual se llega a intimar.

Personalidad también implica cultura y Heritage/1 lleva consigo la cultura de los 70s que es también la cultura de UNIX. Mi sueño para con ella es regalarle un sistema operativo como Minix, Linux o BSD, y aunque no estoy seguro de que eso llegue a ocurrir, el espíritu de UNIX vive en ella desde esta incipiente etapa de diseño en que todavía se encuentra.

Reconozco, no obstante, que he sido un poco exagerado con la rusticidad. Por ejemplo, me he prohibido utilizar memoria ROM a pesar de que en los tiempos cimeros de UNIX (1975 en adelante) ya las "minis" usaban memoria semiconductora y hasta microprocesadores de 8 bits en labores de apoyo como, por ejemplo, en sus video-terminales. Si Heritage/1 hubiera existido realmente en los 70s, seguramente se hubiera percibido como una máquina "demasiado tradicional" y de diseño poco audaz.

No obstante, la rusticidad (simplicidad) sigue siendo su principal encanto; renunciar a ello sería como aniquilarla antes de haberla hecho nacer. Mi reto —además de hacer que verdaderamente funcione, lo cual es de por sí un gran reto— está en lograr desarrollar software útil capaz de correr en una arquitectura tan simple.

Los estudiosos (o curiosos, como yo) de estos temas, sabrán que UNIX surgió en Bell Labs de manos de Dennis M. Ritchie y Ken Thomson, dos peludos que por aquellos tiempos escribían sus programas en terminales de teletipo empleando lenguaje ensamblador, como todo el mundo. UNIX fue quizás —de acuerdo con un testimonio del propio Dennis Ritchie— el primer "sistema operativo de tiempo compartido" en la historia, o al menos el primero en lograr aceptación masiva. Y esto es importante porque de ello se deriva ese espíritu de colaboración que forma parte de su esencia.

En efecto, antes de UNIX, los programadores solían escribir sus programas a punta de lápiz y papel. Las computadoras trabajaban en modo "batch": tanto datos como programas se entraban desde lectores de tarjeta perforada o cinta magnética y los programadores se contentaban con hacer llegar sus listados al Centro de Calculo, esperar a que los operadores los cargaran, corrieran y probaran, para luego recibir de ellos una lista de fallos detectados.

UNIX, siendo un sistema de tiempo compartido, permitió a los programadores escribir directamente en la máquina (como hacemos hoy), interactuar con ella así como con sus colegas, propiciándose así un entorno cooperativo de trabajo. De hecho, UNIX fue concebido en un inicio como entorno de desarrollo ¡no, como un sistema operativo!

UNIX sorprendió, pues, a sus propios autores. La colaboración salió de Bell Labs hacia las universidades, especialmente la de California, Berkely, donde se le hicieron aportes notables. Mucho antes de que el término "Open Source" fuese popular (o que existiese siquiera), de Berkely salieron cintas marcadas "Berkely Software Distrubution" (BSD), una versión de UNIX que aún continúa desarrollándose bajo ese mismo nombre.

UNIX representa una tradición técnica basada en el respeto a su pasado; un ejemplo vivo está en sus "man pages": aún en las versiones más recientes se pueden leer textos exactos a sus originales de 1972, como la del comando "dc" (desktop calculator), uno de los primeros utilitarios escritos para UNIX en Bell Labs.

No puedo garantizar que Heritage/1 correrá UNIX alguna vez. Lo que sí garantizo es su lealtad a la tradición que su propio nombre representa. Los tiempos de Heritage/1 son los tiempos genuinos de Rolling Stone, "Pease and Love" y "K.I.S.S" (Keep It Simple, Stupid).

Virtual Memory

2009-12-30T22:42:00.000-05:00

Por ahora, Heritage/1 no proverá soporte de hardware para Virtual Memory. Pienso que no será difícil implementarlo en un segundo paso (después que la máquina se encuentre "en explotación") y hacerlo de manera que encaje dentro de la arquitectura, sin violentarla.

¿Por qué Virtual Memory? —Porque, contrario a lo que imaginé en un inicio, Virtual Memory no es un "lujo"; por el contrario: su carencia constituye una limitación bastante seria cuando se piensa en un sistema operativo propiamente dicho. Pasará algún tiempo antes de verme enredado en estas cuestiones pero el momento llegará, y estaré yo tratando de portar un "UNIX-like" OS como Minux ó netBSD, tarea esta que no creo viable (o siquiera posible) en una máquina sin soporte para Virtual Memory.

Cuando me asomé a estos tópicos por primera vez (hace solo seis meses) tuve la impresión de que el papel de Virtual Memory está más en la protección de procesos y el establecimiento de un modelo lineal de memoria para las aplicaciones con las cuales el OS se compromete con más memoria (virtual) de la disponible fisicamente (gracias al "swapping"). Tal vez por eso no me pareció especialmente atractivo dentro de un diseño que se jacta de simple. Ahora, sin embargo, estoy viendo los beneficios de Virtual Memory en otro sentido, y tiene que ver con la carga de programas en memoria.

El OS (o más bien un componente suyo llamado "loader") es responsable de cargar cada programa de storage a memoria y cuando lo hace, necesita "relocalizarlo", esto es, cambiar (al vuelo) las instrucciones de control de flujo (como JP y CALL) en concordancia con la dirección base asignada al programa en cuestión.

En realidad he planeado evitar la necesidad de "relocalización" mediante el uso de instrucciones de direccionamiento relativo (lo cual me sigue pareciendo una buena idea); pero aún usando instrucciones de direccionamiento directo, un loader puediera recalcular todos los saltos sin demasiada dificultad (según me parece) aunque consumiendo algún tiempo en ello, por supuesto.

La solución elegante, no obstante, sería realizar la carga del programa en el dominio de la memoria lineal, proveido por Virtual Memory, para lo cual el hardware deber proveer el debido soporte. En tal caso, cada programa contaría con su propio espacio virtual de direcciones de memoria el cual comprende todo el espacio direccionable (64K); el hardware se encargaría de mapear las direcciones de cada aplicación al espacio real de memoria fisica instalada; el OS se encargaría de mantener dicho mapeo y, por añadidura, implementar reglas de protección de procesos. Y el "loader" se limitaría a mapear el nuevo programa dentro del sistema de Memoria Virtual.

Mas, como dije al principio, el tal soporte será implementado en un segundo paso, una vez que Heritage/1 se encuentre "en explotación".

Ocho bits versus dieciséis

2009-12-28T04:44:00.001-05:00

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é].

¿Cuan útil será Heritage/1 en la práctica?

2009-12-24T04:23:00.000-05:00

Ya he dicho que Heritage/1 ha querido ser una computadora "vieja" pero "útil". Sin emgargo, y aún suponiendo que el hardware llegara a funcionar fiablemente, Heritage/1presenta limitaciones serias aún dentro del marco de "su época" (1966-1972).

La primera limitación está en el caracter estrictamente personal (un solo contribuyente) de este proyecto, lo cual limita especialmente el desarrollo de software: por más que me esfuerce no podré llegar muy lejos desarrollándolo todo, desde el sistema operativo hasta las aplicaciones, a golpe de ensamblador y sin el más mínimo sustento de código previo.

Portar código Open Source no es posible de momento dado que la arquitectura de Heritage/1 es demasiado primitiva para el código Open Source existente; por ejemplo, Heritage/1 no soporta Memoria Virtual (cosa esta que se puede reparar en el futuro construyendo una MMU que lograra insertarse dentro de la arquitectura existente). Una alternativa sería portar código "ancestral", mas esto constituye una labor arqueológica más que técnica por demás difícil en ambos sentidos.

Consecuentemente, no puedo hacer de la utilitaridad un objetivo central del proyecto. Más bien, la utilitaridad constituye una guia para la experimentación en materia de Software. Mis aplicaciones serán irremediablemente primitivas, pero deberán (eso sí) estar orientadas a labores "convincentes" como, por ejemplo, el manejo de base de datos. El objetivo final no es utilizar la máquina para resolver problemas del día-a-día, sino experimentar con el desarrollo de aplicaciones "de la vida real" dentro del contexto histórico de Heritage/1 (1966-1972).

La única via para llegar lejos (tanto como llegaron las minis en los 70s) sería la colaboración entre cientos de programadores a lo largo de la Internet, es decir, convertir a Heritage/1 en un proyecto cooperativo. Mas para ello H1 debería resultar suficientemente atractiva y no creo que ese sea el caso.

La pregunta inicial no puede pues responderse con demasiado optimismo. La máquina está diseñada para realizar labores útiles, mas en la práctica será tan útil como mi paciencia lo permita.

Interconexión ALU-Acumulador

2009-12-20T00:42:00.000-05:00

Heritage/1 es (o pretende ser) una computadora de diseño "clásico", y como tal emplea un "Acumulador" (registro A) que trabaja en colaboración con una típica Unidad Logica Aritmética (ALU). Esta última consta de 16 circuitos puramente combinacionales cuyas salidas alimentan un bus interno llamado "Result Bus" (R-BUS).

Cada uno de estos circuitos combinacionales posee dos entradas de 16 bits y una salida también de 16 bits. Las entradas están permanentemente alimentadas desde el Data Bus interno del CPU (D-BUS) y la salida del Acumulador respectivamente. La salida conecta al R-BUS mediante un buffer de tercer estado; en particular, el primero de estos circuitos no hace más dejar pasar el D-BUS a su salida sin combinarlo con el contenido del Accumulador, lo cual permite usar a A como un registro ordinario.

Las instrucciones lógico-aritméticas generan señales de control para que el correspondiente circuito de la ALU (por ejemplo, el de la Adición) abra su salida al R-BUS mientras los otros permanecen en tercer estado, luego de lo cual se comanda al Acumulador para almacenar el resultado (R-BUS).

En el siguiente diagrama de bloques del CPU, puede verse cual es la interconexión entre el Acumulador (A) y el ALU.

Francamente, este arreglo fue el primero que me vino a la mente; después de diseñado, sin embargo, he visto que no es lo más común ni en computadoras comerciales ni en proyectos personales similares a Heritage/1. Lo común (según he visto) es colocar el Acumulador "antes" del ALU, permitiendo que el resultado de la operación lógico-aritmética calculada por el mismo vaya directamente al bus de datos.

En el siguiente diagrama en bloques del microprocesador Intel 8085 puede apreciarse ese tipo de arreglo.

La ventaja es obvia: el resultado de una operación lógica-aritmética puede quedar en cualquier registro del CPU (no solo en A) lo cual evita el tener que moverlo en un paso ulterior. Sin embargo, hay un precio a pagar: la necesidad de un registro temporal alimentando la otra entrada del ALU, como puede apreciarse en la figura anterior.

El diseño de Heritage/1 tiene entre sus premisas el menor uso posible de registros temporales y de hecho no utiliza ninguno. Esto es en el ánimo de ahorrar ciclos de reloj en la ejecución de las instrucciones, asi como simplificar los circuitos en cuestión. De modo que utilizar un registro temporal para la ALU significaría una ruptura de la tal premisa.

El precio a pagar es la imposibilidad de guardar el resultado de una operación lógico-aritmética en otro registro que no sea A, como se ilustra en el siguiente segmento de código:


; Sumar contenidos de B y D 
; depositando el resultado en C
mov a, b
add a, d
mov c, a
; Con una arquitectura diferente, hubiera tomado 
; una sola instruccion:
; add b, d, e

Reconozco que es una limitación impuesta al programador —¡que seré yo mismo a fin de cuentas!— pero la asumo en aras de preservar un diseño de hardware simple donde el uso de registros temporales es una especie de heregía.

Controlador micro-programado para Periféricos

2009-12-13T14:34:00.000-05:00

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. Había concebido, pues, 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 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 de mi controlador pero sí, a intimar satisfactoriamente con el concepto, el cual trataré de explicar en lo que sigue.

UNA MAQUINA CON PROGRAMA ALMACENADO

La primera vez que leí en el manual de una computadora legendaria algo parecido a esto: “This is a sequencial, stored-program, parallel digital computer”, 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 los tiempos anteriores a 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. La primera ha dominado por décadas pero en este siglo XXI estamos rompiendo ese esquema para movernos rápidamente hacia el procesamiento concurrente.

LA COMPUTADORA VISTA COMO UN FINITE STATE MACHINE (FSM)

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 llegaría mucho más lejos si no existiese la necesidad de tomar desiciones en base a los datos de entrada. ¿Qué hace una computadora, a fin de cuentas? Correr secuencias… ¡y nada más! La grandeza parte de que dichas secuencias no son fijas sino que toman diferentes rumbos en dependencia de los datos de entrada y de los resultados intermedios. Y más grandioso aún es el hecho de que una buena parte de esos “datos” se utilizan para direccionar el FSM, esto es, constituyen “instrucciones”, el programa en sí: 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, de ahi la necesidad de almacenarlo junto a los datos en el mismo medio.

Hay otro concepto clave en el cual no había reparado sino hasta hoy: la toma de desiciones (próximo estado del FSM) depende también de condisiones establecidas muy anteriormente por resultados intermedios. Es el caso de un número 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, por un tren de pulsos (reloj). 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 M bits, y los conectamos 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; en una computadora "microprogramada" (como es común desde la IBM/360 hasta nuestros días), esto sería el "micro-code" de la máquina y a su memoria la llamaríamos "micro-code storage".

Pero eso no es todo; a decir verdad, 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 principal).

Para que esto ocurra, 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 y los alimentaremos desde del Flags Register (asumiendo que este es de 4 bits).

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

Mi propuesta consite en que, con estos pocos medios, se puede construir una máquina computadora donde el software no resida “como dato” en la misma memoria donde están los datos verdaderos, sino como Tabla de Estados del FSM, en memoria separada. En otras palabras, el "software" de la máquina sería directamente su "micro-code".

Una máquina así 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. La labor a realizar por esta máquina se asume suficientemente simple como para poder programarse directamente como "micro-code".

Pretendo valerme de esta técnica para proveer alguna (escasa) intelegencia a los Device Controllers de Heritage/1. Estos serían tarjetas de circuito impreso alojadas en la unidad de control de cada periférico y su misión consitiría en leer/escribir un buffer desde el medio en cuestión (cinta, puerto serie, impresora, etc) asi como negociar la atención del CPU de acuerdo con la arquitectura de interrupción de Heritage/1.

H1-OS: Multi-Procesamiento

2009-12-09T15:01:00.001-05:00

Siendo Heritage/1 una máquina secuencial, su sistema operativo (H1-OS, al cual llamaremos simplemente OS en este articulo) implementará multiprocesamiento por "lonjas de tiempo", tal como se muestra en la siguiente figura.

En la figura, P1 y P2 son dos procesos "multiprocesados", es decir, multiplexados en tiempos de tal suerte que P1 y P2 corren simultáneamente a los ojos del usuario; OS representa el sistema operativo o, más concretamente, una rutina encargada de producir la conmutación entre procesos. Cada proceso corre continuamente hasta la llegada de una interrupción del TIMER (cada 1 ms) la cual entrega el control al OS.

Ya hemos visto en artículos anteriores que un programa solo existe como tal en Storage; cuando se carga en memoria, se le crea una "instancia" consistente en dos areas: una para código y otra para su área de datos (Stack). Vimos también que un mismo programa puede ser multi-instanciado, en cuyo caso se mantiene en memoria una sola copia del código, pero se crean Stacks separados: uno para cada instancia. Por "proceso" entendemos justamente eso: una instancia de un programa dado; en particular, P1 y P2 pudieran ser instancias de un mismo programa.

ESTADO DE EJECUCION

Cuando un proceso es interrumpido (por el Timer), su "estado de ejecución" debe guardarse en algún sitio de modo que cuando el OS le devuelva el control, él puede continuar su ejecutación exactamente en el punto en que la dejó.

En Heritage/1, el mecanismo de interrupción provee por sí mismo el medio para salvar dicho "estado de ejecución". En efecto, cuando ocurre una interrupción, el Contador de Programa (PC) y las banderas (F) son salvadas automáticamente en el Stack. Pero hemos visto que cada proceso cuenta con su propio Stack de modo que en un momento dado existen varios, uno por cada proceso en multiprocesamiento. Sin embargo, para el mecanismo de interrupción, "Stack" es aquella estructura apuntada por el registro SP (Stack Pointer), y en el momento de la interrupción SP está apuntando al Stack del programa interrumpido de modo que es alli donde se salvan (automáticamente) PC y F.

Moraleja: El estado de ejecución de un proceso dado se salva en su propio Stack.

La interrupción conduce al OS, cuya primera tarea es completar la salva del estado de ejecución del proceso interrumpido, es decir, salvar el resto de los registros en su propio Stack. En el momento inicial, SP sigue apuntando al Stack del proceso, asi que el OS completar la salva mediante sucesivas instrucciones PUSH. Por último, el OS salva SP hacia una estructura de datos propia.

La segunda tarea de OS es pasar control al siguiente proceso en turno. Para ello es suficiente averiguar cual es ese proceso y recuperar el Stack Pointer correspondiente (es decir, cargar SP con tal valor). Una vez hecho esto, SP estará apuntando al Stack del proceso en cuestión donde, como se ha dicho, se encuentra salvado su "estado de ejecución". El OS se encarga entonces de ejecutar sucesivas instrucciones POP para recuperar los registros que él mismo salvó en su momento, luego de lo cual ejectua una instrucción RET (retorno de interrupción). Esta instrucción se ocupa automáticamente de recuperar PC, F, y pasar control al proceso en cuestión, lo cual completa la conmutación.

ESTRUCTURA DE DATOS

Para realizar su labor de arbitraje, el OS se vale de estructuras de datos propias. Lo que sigue es solo una primera aproximación pués las estructuras como tal no han sido diseñadas.

PGM

En un arreglo (que llamaremos PGM) se guarda información sobre cada programa disponible. Recuérdese que los programas reciden en Storage, no en memoria. Para que el OS conozca de sus existencia, se precisa de un fichero de configuración donde dichos programas estén alistados. El OS lee ese fichero durante su carga y crea, a partir de él, el arreglo PGM donde se especifican cuales programas están disponibles y dónde encontrarlos en Storage.

PROC

En un arreglo (que llamaremos PROC) se guarda información sobre los procesos participantes del multiprocesamiento. Inicialmente el arreglo estará vacío, o tal vez contenga información sobre procesos del sistema operativo automáticamente lanzados (como el Shell). Cada elemento del arreglo especifica, entre otros datos, la dirección en memoria del Codigo y la del Stack del proceso en cuestión.

Cada vez que se instancia un proceso, se crea un nuevo elemento en el arreglo PROC. Si se trata de la primera instancia, el programa correspondiente será cargado desde storage. El mecanismo de conmutación del OS se guia por este arreglo para realizar su arbitraje.

SESSION

Suponiendo que el sistema puede accederse desde varios terminales a la vez, el concepto de session representa una "jornada de trabajo" desde la perspectiva del visitante. Sin embargo, la session no es un concepto inherente al multiprocesamiento. Sobre esto hablaremos más adelante en un artículo dedicado a "Multi-Usuario".

SERVICIOS DEL SISTEMA OPERATIVO

Aparte de la rutuna de arbitraje de multiprocesamiento que acabamos de ver, el OS ofrece otros servicios, especialmente a las aplicaciones, como acceso a los perifiéricos, alojamiento de memoria etc.

Las aplicaciones solicitan estos servicios mediante interrupciones de software (instrucción INT), a lo cual llamamos "llamadas al OS" o (en inglés) "System Calls".

Cuando una aplicación realiza un System Call, el CPU pasa control a la rutina de interrupción especificada, la cual forma parte del OS. Lo primero que hace esta rutina es desabilitar la interrupción del Timer para no ser perturbada durante su trabajo. Y esto es importante: una rutina de interrupción del OS detiene el multiprocesamiento, esto es, paraliza el sistema para concentrarse enteramente en esa tarea del OS.

Estas rutinas han de ser, pues, breves y consisas. Sus tareas son tales como reserva de memoria, iniciación de periféricos etc. Una vez concluida su breve labor, la rutina pasa control al corazón del OS quien se ocupará entonces de conmutar al siguiente proceso en turno.

Pero el OS también ofrece serivicios "prolongados" que no pueden escribirse como breves rutinas de interrupción. Tal es el caso, por ejemplo, de rutinas de tratamiento de datos como: Ordenación, búqueda, o tal vez una aritmética de punto flotante. Estos servicios se instrumentan como programas del Sistema Operativo (a los cuales llamamos Servicios) y se les hace participar del multiprocesamiento como procesos ordinarios. Para hacer uso de ellos, una aplicacion realiza un system calls cuya rutina de interrumpción se limita a establecer el puente entre la aplicación y el servicio.

RELACIONES DE PARENTEZCO ENTRE PROCESOS

Así como un proceso puede solicitar un servicio del OS (el cual es, como vimos, otro proceso), un proceso puede también arrancar a otro proceso no perteneciente al sistema operativo. Es el caso, por ejemplo, del "run-time library" de un lenguaje (sobre este tema en particular volveremos en otros artículos).

Supongamos que existe un servicio para ordenar listas; llamémosle QUICK-SORT. Para utilizarlo, un proceso tiene que realizar un system call pasando como argumento la dirección de la lista en cuestión asi como su tamaño. Seguramente, al proceso no le interesa continuar su ejecución hasta tanto QUICK-SORT haya concluido su trabajo ya que nada puede hacer con una lista a medio ordenar.

Recuérdese que un servicio participa del multiprocesamiento, de modo que su trabajo transcurre "simultáneamente" con la del proceso que lo llamó. De modo que muy probablemente el OS regrese control al proceso antes de que QUICK-SORT haya concluido su labor, contrario a lo que se quería.

La forma de evitar esta situación es estableciendo relaciones de parentezco entre procesos. En este caso, el proceso en cuestión es "padre" de la instancia (proceso) de QUICK-SORT que el OS creó bajo solicitud. Y la regla es que el padre se detiene hasta tanto el hijo haya terminado su ejecución.

"Detener un proceso" en multiprocesamiento significa que, llegado su turno, el OS no le pasará control a él sino al siguiente proceso en turno. Ello se logra mediante el uso de "semáforos" que, en esta caso, puden ubicarse en el mismo arreglo PROC.

Otra ventaja de establecer relaciones padre-hijo entre procesos se refiere a limpieza y mantenimiento: Cuando un proceso padre muere, deben morir todos sus hijos, lo cual evita ocupar imnecesariamente el espectro de multiprocesamiento.

PROCESAMIENTO MULTI-HILOS

La regla establecida en el epígrafe anterior (el padre se detiene mientras el hijo se está ejecutando) no es estricta sino solo una opción. Puede darse el caso en que un proceso no necesite esperar por los resultados del servicio solicitado. Por ejemplo, imprimir un documento mientras continúo con otros cálculos no relacionados con la impresión.

En tal caso, la aplicación haría el system call especificando que no desea ser detenido. Como resultado, un proceso correría "simultáneamente" con sus hijos, lo cual no es otra cosa sino "multi-hilos" (multithreading).

MULTI-USUARIO

Multiprocesamiento no implica directamente Multi-Usuario. Sobre este tema abundaremos en articulo separado dada su extención.

Uso de Storage en Heritage/1

2009-12-09T02:24:00.001-05:00

Antes que un disco duro, Heritage/1 tendrá V-TAPEs por storage. Ya he mencionado que un V-TAPE es (o será) un diskette de 3.5 pulgadas con un file system (propietario) diseñado para simular una cinta magnética.

Hasta ahora, he imaginado que un V-TAPE aloja tan solo a un fichero, pero ello representa un desperdicio de espacio, obviamente; es muy posible, pues, que diseñe el file system de manera que permita más de un fichero por V-TAPE. Supongamos que ese es el caso; entonces será mi opción alojar uno o más de uno por V-TAPE. Yo creo que en el caso de bases de datos (o ficheros de datos en general) preferiré un solo fichero por V-TAPE ya estos ficheros irán creciendo con el tiempo, mientras que para programas preferiré varios ficheros por V-TAPE ya que los mismos son de longitud fija y así podré aprovechar mejor el espacio del diskette.

El lector se preguntará cual es problema si el diskette es un medio de acceso aleatorio. La respuesta es que un V-TAPE no es tal cosa puesto que su file system lo obliga a comportarse como una cinta y es como tal qie hay que pensarlo. La cinta es un medio de acceso secuencial; no se puden hacer inserciones sino tan solo añadir datos al final o reemplazar el fichero en su totalidad. De ahi que alojar varios ficheros en una sola cinta imposibilite la actualización de los mismos. Estoy conciente que estos procedimientos suenan arcaicos al oido de un hombre moderno, pero de eso se trata: de saborear los problemas del pasado.

BASES DE DATOS

Habrá adevertido del lector curioso de la Historia que los centros de cálculos de antaño empleaban un gran número de lectores de cinta. Yo creo que no era tanto para aumentar la capacidad total del sistema sino, más bien, para posibilitar la operación con un gran número de ficheros simultáneamente.

Pongamos el caso de una aplicación de base de datos típica. Hoy en día estamos acostumbrados a diseñar bases de datos acorde con el Modelo Relacional; pensamos en "tablas" divididas en "columnas", establecemos vínclulos entre ellas, y nos despreocupamos de la "plomería" que le subyace ya que el DBMS empleado (MySQL, MS SQL Server, etc) se encarga de esos por menores. Lo cierto es que casi todos los DBMS modernos crean un fichero en disco por cada "tabla" de nuestra base de datos, así que una aplicación, que típicamente emplea un gran número de tablas, utilizará un gran número de ficheros en disco.

Nosotros no usaremos disco sino V-TAPEs, y ya hemos visto que cada fichero emplea un V-TAPE para sí, de modo que un gran número de ficheros implica un gran número de V-TAPES, que es lo mismo que decir: un gran número de lectores de diskettes. Esto impone una seria restricción al diseño de nuestras bases de datos: hay que usar la menor cantidad posible de "tablas".

Dicho sea de paso, nosotros no usaremos el Modelo Relacional, sino el jerárquico por ser este el preponderante en tiempos de Heritage/1.

FICHEROS PERMANENTES Y FICHEROS DE MOVIMIENTO

He aqui un concepto perdido en el tiempo ya que, hoy en día, actualizar un fichero en disco no representa ningún problema. Pero tal no era el caso en los tiempos de las cintas magnéticas.

Ya hemos visto que la única manera de actualizar una cinta que contiene varios ficheros es reemplazarlos todos por sus nuevas versiones, es decir, la cinta en su totalidad. En la práctica, esto significa, más bien, leer la vieja cinta al tiempo que se crea una nueva con los nuevos datos (usando dos lectores de cinta)... recuérdese que en aquellos tiempos la memoria era limitada y muy posiblemente no alcanzaba para alojar un fichero en su totalidad.

La moraleja de esta intersante historia es que la actualización de ficheros en cinta es algo digno de ser evitado. Una manera de minimizarlo es mediante el uso de "ficheros permanentes".

Consideremos el caso de un Sistema de Control de Personal. Hay una gran cantidad de información sobre cada empleado, pero no se reclutan ni despiden empleados a diario, asi que dicha información es poco susceptible de cambios. A estos ficheros les llamamos "permanentes".

En contraposición, existe información de cambio frecuente, como horas trabajadas por día, vacaciones, etc. Esta información la guardamos en "ficheros de movimiento". La tarea cotidiana del sistema consiste en actualizar los ficheros de movimiento y luego generar salidas en base a estos, con referencia a los permanentes. Por ejemplo, la salida "Pedro Pérez tiene 4 horas de tiempo exta esta quincena" se genera en base a información permanente sobre Pedro Perez (incluido su horario habitual de trabajo) y las horas trabajadas las cuales se han registrado a diario (movimiento).

La ventaja de usar ficheros permanentes es que podemos almacenar más de un fichero en una misma cinta, lo cual ahorra lectores. En caso de tener que actualizarlos (reclutamiento de un nuevo empleado, por ejemplo), habrá que producir una nueva cinta (permanente) que constituye una versión actualizada de la vieja.

La moraleja es esta: El sistema ha de diseñarse tratando de concentrar los movimientos en la menor cantidad posible de ficheros, maximizando el uso de ficheros permanentes.

FICHEROS DE PROGRAMA

Estamos hechos a la idea de que nuestro PC es una especie de "resuélvelo todo" y por tanto debe alojar una inmensa cantidad de programas aunque solo utilicemos unos pocos en la práctica diaria. Ello se deriva del hecho de ser, nuestro PC,(y como su nombre lo indica) una "Computadora Personal".

En el mundo industrial es más común encontrar computadoras (aún PCs) dedicadas a una función única, pero aún en tales casos sus sistemas operativos (Windows, Linux, etc) vienen con una inmensa cantidad de programas pre-instalados con el fin de prestar diversos servicios de plataforma y aún aplicaciones.

Tal no es (definitivamente) el caso de Heritage/1, como no era el de sus congéneres allá por los 70s tempranos.

Si Heritage/1 prestara servicios en una Biblioteca Publica, por ejemplo, estaría dedicada por entero a mantener el Catálogo de la Biblioteca, es decir, una y solo una aplicación por el resto de su vida útil.

Los ficheros de datos recidirían en varios V-TAPES peremnemente montados en sus respectivos lectores. Dos V-TAPEs adicionales estarían reservados para los programas: Uno para el Sistema Operativo (H1-OS) y otro para la aplicación en sí.

Cada vez que hubiese que iniciar el sistema, el Operador entraría el "Loader" en memoria usando para ello la Consola y este pequeño programa se encargaría de cargar H1-OS en memoria procedente de V-TAPE. Seguramente H1-OS consta de varios ficheros de programas, todos ellos recidentes en el mismo V-TAPE... o tal vez tome varios y entonces el Operador tenga que hacer marabares cambiando V-TAPEs en varios lectores durante la carga.

Ya con el Sistema Operativo en ejecución, el Operador montaría el V-TAPE de la aplicación y, a golpe de comandos, instruiría a H1-OS para cargarla en memoria. Ya para entonces los V-TAPES de datos habrían de estar montados en sus respectivos lectores; los clientes de la Biblioteca podrían entonces hacer uso del sistema desde terminales instalados en el salón.

¿CUANTOS LECTORES?

He pensado en una provición incial de 8 lectores de V-TAPE. Este número mágico sale de una cuenta muy sencilla: eso es lo que cabe cómodamente en 19 pulgadas de rack. Seguramente uno estará reservado para el Sistema Operativo, asi que cuento con 7 para mis aplicaciones de base de datos, cualesquiera que estas sean.

Curiosamente, estoy diseñando una simple base de datos para resolver un problema persornal concreto y, hasta ahora, solo estoy ocupando 5 ficheros... asi que la restricción no ha demostrado ser demasiado severa... hasta ahora.

H1-OS: Alojamiento de programas en Memoria

2009-12-06T05:09:00.000-05:00

Los tiempos de comenzar a escribir un sistema operativo (H1-OS) para Heritage/1 están lejos aún, pero asomarme al tema desde ahora me ha servido para garantizar desde diseño el debido soporte de hardware. Por ejemplo, pensando en cómo un sistema operativo haría para alojar diferentes programas en memoria, he llegado a comprender la necesidad de incluir "direccionamiento relativo" en el diseño del set de instrucciones del CPU.

DIRECCIONAMIENTO RELATIVO

El Contador de Programa (PC) de Heritage/1 está diseñado para incrementarse en una unidad (PC = PC + 1), cargarse con una dirección dada (PC = ADDR), o para sumar su contenido con un operando dado (PC = PC + OFFSET). Esto corresponde a los modos de direccionamiento: implícito, directo y relativo respectivamente.

Un programa que utilice saltos relativos solamente será fácilmente ubicable en cualquier sitio dentro de la memoria ya que al programa no le importa "a dónde saltar" sino "cuan lejos", tal como se ilustra en el siguiente ejemplo.


400 mvi d, 1000  ; apunta a variable en 1000
402 ldx a, d  ; lee variable (indirecto)
403 jr 5  ; salta 5 direcciones hacia adelante
...
408 ; el salto occurrirá a esta dirección.

Si este segmento de programa se carga en una dirección diferente a 400, el salto seguirá funcionando igual, lo cual era el propósito. Sin embargo, no podemos decir lo mismo si ubicamos la variable en una dirección diferente a 1000.

Lamentablemente (y por razones de economía) solo estoy implementando el direccionamiento relativo para PC y especificamente para las instrucciones de salto. La solución para la relocalización de variables proviene de la forma en que H1-OS cargará los programas en memoria y cómo estos estarán estructurados.

ANATOMIA DE UN PROGRAMA EN HERITAGE/1

Los programas reciden en "storage" (V-TAPE) en forma de ficheros. Estos consisten en una etiqueta (LABEL), un cuerpo que contiene el código ejecutable (Code) y un caracter de fin de fichero (EOF).

La etiqueta contiene información a cerca del programa, incluyendo los requerimientos de su área de datos, esto es, el tamaño del Stack. Al cargarlo en memoria, el Sistema Operativo (H1-OS) aloja el código en el primer lugar disponible de memoria y reserva otra porción para su área de datos (Stack) tal como ilustra la siguiente figura.

Como este no será el único programa coexistente en Memoria, H1-OS mantiene una tabla de todos los programas cargados, guardando en ella la dirección del Código y Stack asignados. Antes de pasar control al programa, carga SP con el valor correspondiente (SP' = OS_VAR + TAMAÑO_ASIGNADO_AL_STACK).

Cuando el programa entra en ejecución, el registro SP está apuntado al fondo de su Stack; lo primero que hace el programa como tarea de inicialización es organizarlo. Pongamos por ejemplo (ver figura) que este programa utiliza dos variables globales: un entero de 16 bits llamado N, y un doble de 32 bits llamado X. Para reservar memoria para ambas variables, el programa corre SP tres pasos hacia arriba (SP = SP' -3). A partir de ese momento, el Stack propiamente dicho queda "encima" de las variables globales del programa. El programa accede entonces sus variables como "distancias" relativas a la posición actual de SP.

El siguente ejemplo ilustra lo explicado anteriormente.


; Reservación de memoria para las variables globales.
dec sp ; Reservada memoria para N
dec sp
dec sp;  Reservada memoria para X
...
; Lee variable N en A:
mov a, sp  ; A = SP
adi a, 3   ; A = A + 3
mov d, a   ; D = A (es decir: SP + 3)
ldx a, d   ; A = [D] (es decir, variable N)

Un programa típicamente llama a funciones suyas utilizando la instrucción CALL. Cuando esto ocurre, tanto PC con F se salvan automáticamente en el Stack (justo encima del área de variables pues allí fue donde quedó posicionado). El código de la función moverá a su vez SP para crear su propia area de datos tal como lo hizo el programa principal y las accederá de igual manera. Cuando la función retorne, dicha area se liberará queando SP en su posición original, es decir, justo encima de de las variables globales. Este proceso se puede repetir recursivamente hasta que el tamaño del Stack lo permita.

INSTANCIAMIENTO MULTIPLE

H1-OS permite el instanciamiento múltiple de programas, esto es, la existencia de varias copias de un mismo programa corriendo simultáneamente en memoria. Lo que hemos hecho hasta ahora (cargar un programa en memoria) no es más que crear una primera "instancia" del mismo. Para crear una segunda, no hay que volver a traer el código desde V-TAPE sino tan solo crear un segundo Stack para el mismo código. De esta manera, ambas instancias utilizarán la misma copia del código pero tendrán áreas de datos separadas, una para cada instancia.

El instanciamiento múltiple es vital para el Multi-Procesamiento, como explicaremos en el próximo artículo.

Desarrollo de Software

2009-12-05T23:50:00.000-05:00

Cuando Heritage/1 exista como hardware (Mayo 2010), habrá llegado el momento de comenzar a escribir software para ella. Pero ¿cómo se escribe software para una plataforma propietaria? Porque los sistema de desarrollo convencionales generan código dirigido a un sistema operativo específico y/o CPU específico, no para un entorno recién nacido y único del que nadie tiene noticias.

Una alternativa es escribirlo todo en código de máquina, pero por esa vía no se puede llegar muy lejos. Otra opción es escribir uno sus propias herramientas de desarrollo, pero ello constituye un proyecto en sí, mucho más complejo que el software que se escribirá después.

Afortunadamente existen herramientas para este menester, tanto comerciales como "Open Source", y aquí caemos en el mundo de los ensambladores "redirigibles" (retargetable) y en la tarea de "portar" código fuente de una plataforma a otra.

Asumamos que ya hemos resuelto ese problema, de modo que ahora podemos escribir código ensamblador y generar ficheros binarios que el CPU de Heritage/1 pueda correr. Este desarrollo lo hacemos utilizando un PC, por supuesto; los ficheros binarios resultantes se hacen llegar a la memoria de Heritage/1... de alguna manera.

UN CEREBRO INICIALMENTE VACIO

Una de mis premisas para el diseño de Heritage/1 ha sido que el Software es algo "externo" a la computadora. Esto implica que H1 no tiene memoria ROM ni ningún otro medio para almacenar un programa de arrancada. Cuando la computadora se enciende, nada ocurre más allá de un reset de hardware: la computadora despierta con inteligencia cero.

El software reside pues en "storage" (posiblemente V-TAPES) mas para hacerlo llegar a memoria se precisa de un programa de arrancada o "Loader" (cargador). Este programa es en realidad pequeño y se entra mediante la Consola, word a word, bit a bit (sería esta la tarea del Operador cada mañana a su llegada al centro de cálculo). Una vez entrado el Loader, el Operador presiona el botón "START" con lo cual el CPU comienza a ejecutarlo. Ya en ejecución, el Loader se ocupa de cargar el Sistema Operativo desde un V-TAPE previamente colocado en su lector. Con el Sistema Operativo cargado y en ejecución, Heritage/1 habrá ganado la inteligencia necesaria para comenzar su trabajo útil.

PRIMER PASO: BATCH PROCESSING

Con suerte, tezón y mucha paciencia, un Sistema Operativo propiamente dicho aparecerá en su momento. Pero habrá un primer período de experimentación, por supuesto, donde todos mis programas serán entrados directamente en memoria, bit a bit, mediante la Consola. En estas condiciones habré de crear mi acceso a "storage" y/o (tal vez) a un puerto serie con vistas a proveerme una vía para la entrada en memoria de software voluminoso desde un medio externo como un PC o un V-TAPE. Una vez levantados estos cimientos, estaré en condiciones de edificar un Software de Sistema más o menos serio.

Mi plan de desarrollo consiste en hacer que Heritage/1 atraviese escalonadamente ciertos "estadíos históricos" en cuanto a modo de operación se refiere.

La Historia nos enseña que por toda una década (1950s) las computadoras trabajaron exclusivamente en modo "batch". Esto se refiere a la habilidad de una computadora para correr varios programas en cascada, uno a continuación de otro, sin intervención humana entre la terminación de uno y la arrancada del siguiente.

Hoy nos parece que "batch" es lo contrario de "interactivo", pero en el momento de su introducción (principios de los 50s), "batch processing" representó una alternativa a tener que detener la máquina cada vez que un programa terminase y tomarse el tiempo de prepararla para el programa siguiente. El procesamiento "batch" consiguió amentar la eficiencia global de la máquina a costa de minimizar los tiempos muertos del CPU.

Una computadora como Heritage/1 pudiera prestar servicios en un Centro de Cálculo de aquellos tiempos, operando en modo "batch". En lugar de usuarios, habrían operadores profesionales y en lugar de Sistema Operativo, un simple programa "Monitor" encargado de leer las especificaciones de los programas a correr y administrar automáticamente su carga y ejecución atendiendo a prioridades y disponibilidad de recursos.

La verdadera Heritage/1 tendrá, pues, su "Batch Monitor" y operará en modo "batch" por algún tiempo. Será este el momento de refinar las técnicas de programación y (no lo dudo) hacer ajustes al hardware del CPU y los periféricos.

Luego vendrá una etapa mucho más interesante: Multiprocesamiento, pero de eso hablaré en artículo separado, dada la extensión del tema.

Breve descripción del CPU

2009-12-05T05:32:00.000-05:00

Una de mis premisas para el diseño de Heritage/1 ha sido la simplicidad. La siguiente figura muestra un diagrama en bloques de su CPU.

El registro A es el "acumulador", encargado de recoger el resultado de toda operación procedente de la Unidad Logica Aritmética (ALU). SP es el Stack Pointer" (puntero de la pila). PC es el "Program Counter" (contador de programa). IR es el "Instruction Register" (registro de instrucciones), encargado de recibir el código de la instrucción. OR es el "Operand Register", encargado de recibir el operando (si existe) que acompaña a la instrucción. F es el "Flags register" (registro de banderas). B, C, D y E son registros de propósito general.

Los registros F, IR y OR se consideran "ocultos" ya que el programador no tiene control sobre ellos. Especiales también (aunque no ocultos) son PC y SP ya que el programador no dispone de instrucciones para manipularlos directamente.

Excepto F (8 bits), todos los registros son de 16 bits, asi como los buses de Dirección y Dato. Esta simetría representa una gran ventaja de la que Heritage/1 ha tomado el siguiente partido: todos los registros (excepto A, F, IR) pueden escribir tanto sobre el bus de datos como sobre el de direcciones, lo cual facilita el direccionamiento indirecto y elimina la necsidad de los llamados "registros índices". Sirva de ejemplo el siguiente código:


mvi d, 0x400 ; D <- 400H (direccionamiento inmediato)
ldx a, d     ; A <- [D]  (direccionamiento indirecto)

Siendo el bus de direcciones 16 bits, el mismo puede direccionar hasta 64 KWords de memoria. Y digo "words" porque Heritage/16 es estrictamente 16-bits, esto es, su memoria está organizada en términos de 16-bits words, no Bytes.

Pero aún pensados como 128 KB, resulta una cantidad limitada desde nuestra perspectiva moderna. Sin embargo, la mayoría de las minis en los 70s venían equipadas con mucho menos (típicamente 16 Kwords). De modo que una provición de 64 Kwords me parece decente dado el software que Heritage/1 será capaz de correr en la práctica, y a la vez consecuente con su "contexto histórico".

En el diagrama se observan bloques asociados a interrupciones de hardware (Interrupt Controller y Timer). En efecto, Heritage/1 soporta interrupciones tanto de hardware como de software, pero no voy a cubrir el tema en este momento; para abundar sobre el mismo, referirse a:

Interrupt Architecture.

Solo voy a mencionar la misión del Timer; este circuito es en realidad un contador alimentado por el reloj (4MHz) y alambrado para generar una interrupción cada 1 ms. Esta interrupción constituye el "tic" de la máquina y está pensada como soporte de un Sistema Operativo de tiempo compartido... el cual tendré que escribir desde cero y espero poder llegar a hacerlo.

En mis notas (sobre el papel), me he demostrado a mi mismo que estos pocos recursos alcanzan para correr software útil sobre un Sistema Operativo multi-usuario con multi-tarea preventiva. Los detalles los explicaré más adelante en otros artículos.

¿Qué es Heritage/1?

2009-12-05T03:02:00.001-05:00

Heritage/1 es (o será) una máquina no muy diferente a la legendaria DEC PDP-11. Como aquella, está construida en base a circuitos integrados de baja y mediana escala de integración, es decir, no usa un microprocesador, y no está concebida para operar como computadora personal sino como "main frame": los usuarios se conectarán a través de terminales remotas via RS232.

El no uso de circuitos de alta escala de integración (LSI) hace de Heritage/1 un equipo voluminoso de aspecto industrial consistente en varios módulos montados en un rack industrial de 19 pulgadas con 20 RU de altura. Entre esos módulos figura la Unidad Central de Procesamiento (CPU): un "frame" de 4 RU donde reciden 18 tarjetas de circuito impreso. Otros módulos comprenden (separadamente): la Memoria, los Puertos RS232, Discos, etc.

En el frente del CPU hay una Consola de mando cuyo aspecto recuerda, más bien, las minis transistorizadas de mediados de los 60s (como la DEC PDP-8). Para ser justos con la Historia, este tipo de consola tan prominente desapareció rápidamente apenas entrados los 70s. La Consola está pensada para un "Operador" y/o programador, no para un usuario; desde ella se puede monitorear y manejar la marcha del CPU mediante interruptores y lámparas (LEDs).

Hay que decir que Heritage/1 es un "prototipo" y por tanto se ha construido sobre tarjetas de prototipo. Y también, que al rack principal pueden añadirse otros en el futuro ya que se trata de un proyecto abierto cuyo principal objeto es la experimentación.

No cualquier tipo de experimentación, valga la aclaración. Se trata de "experimentar con el pasado". Por ejemplo, en "los tiempos de Heritage/1" el uso de discos duros no era frecuente en minicomputadoras de configuración básica (dado su costo) siendo muy común el uso de cintas magnéticas y perforadas. No se había inventado el Modelo Relacional de bases de datos por lo que se usaban otros, notablemente el llamdo Jerárquico. Tampoco se había inventado el lenguaje C por lo que los sistemas operativos se escribían enteramente en lenguaje ensamblador.

Confiezo, no obstante, que me he visto forzado a introducir ciertos "anacronismos" en Heritage/1. Por ejemplo, he tenido que usar memoria semiconductora en lugar de Ferrita y en lugar de circuitos integrados TTL he utilizado HCMOS por ser estos inconmensurablemente más económicos en consumo de energía.

Pero la principal conseción he tenido que hacerla con el "storage" (memoria de masa). No pudiendo ¡ni soñar siquiera! con el uso de cintas magnéticas, he concebido la idea de simularla mediante diskettes de 3.5 pulgadas; para ello, he implementado un "file system" de a un solo fichero por diskette al cual he dado en llamar "V-TAPE" (Virtual Tape, o cinta virtual).

Otra confeción... nada de lo anterior existe más que en el papel. Aparte de los dibujos (algunos de los cuales van por su décima revisión), existen imnumerables notas, incluidas largas discusiones conceptuales conmigo mismo. En otras palabras, Heritage/1 está en fase de diseño.

Un diseño que ha madurado mucho a lo largo de seis meses y que está pronto a entrar en su fase de "desarrollo escalonado", es decir, construcción y puesta a punto de un circuito tras otro.

Y como todo diseño, el de Heritage/1 ha sifrido cambios drásticos, tumbos hacia atrás y hacia adelante, antes de alcanzar la citada maduréz. Algo sin embargo ha prevalecido desde el primer día: Heritage/1 ha querido ser una computadora "vieja" pero "útil". En sus tiempos, máquinas similares controlaron procesos industriales, jugaron ajedréz y condujeron al hombre al Cosmos. Si aquellas pudieron hacerlo, entonces Heritage/1 podrá hacerlo también... en principo, al menos.

Introducción

2009-12-05T00:35:00.001-05:00

Heritage/1 es un proyecto personal iniciado en Julio de 2009, actualmente en desarrollo y cuya fecha de terminación ha sido fijada (tentativamente) para el 1ro. de Mayo de 2010.

Trata del diseño y construcción de una minicomputadora similar a aquellas que existieron entre 1966 y 1972. La primera cota se refiere al año en que aparecieron los circuitos integrados TTL de la serie 7400. La segunda, marca el declive de la memoria de ferrita en favor de la semiconductora (específicamente, Intel 1103 lanzada masivamente en ese año).

Este blog no pretende documentar el proyecto en su totalidad sino dar tan solo noticias de su marcha y —sobre todo— reflexiones en torno al tema. Aún siendo este un proyecto intrincadamente técnico, el aspecto cultural (que también encierra) constutuye un camino no menos intrincado que me interesa trillar.

Para información estrictamente técnica (en inglés), dirigirse a:
http://www.armandoacosta.com/cpu/