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.
Sunday, August 22, 2010
Sunday, August 15, 2010
¿Simulación a nivel circuital?
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.
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.
Thursday, July 15, 2010
La experiencia del Simulador HSIM
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.
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.
Subscribe to:
Posts (Atom)
