💾 Archived View for texto-plano.xyz › peron › articulos › origenes_twenex.gmi captured on 2022-06-11 at 20:58:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Orígenes y desarrollo de TOPS-20
por Dan Murphy
TOPS-20 fue anunciado por primera vez bajo la guisa de producto de DEC y sus envíos comenzaron en enero de 1976. El desarrollo comenzó en 1973 basado en TENEX [1], un sistema operativo para la PDP-10 que estaba en uso en varias instituciones de investigación en todo los Estados Unidos. Hubieron muchos factores involucrados en la decisión de iniciar el desarrollo de TOPS-20, pero fundamentalmente se debió al deseo de DEC de contar con un sistema operativo de memoria virtual para el nuevo procesador KL10 que se hallaba en sus primeras etapas de desarrollo. Aunque se sumaron y quitaron muchos componentes cuando TENEX se convirtió en TOPS-20 de 1973 a 1976, la mayor parte de su arquitectura se mantuvo tal como había sido diseñada en 1969 en Bolt Beranek _ & Newman Inc. (BBN) en Cambridge.
Por lo tanto, para comprender los factores que influyeron en el diseño de TOPS-20, debemos mirar hacia atrás a fines de la década de 1960 y e imponernos en el ambiente existente al momento de crear TENEX. Algunas de las ideas incorporadas a TENEX, y el proceso que finalmente las llevó a DEC, tenían raíces que se remontan a principios de la década de 1960. En esta sección, rastrearemos estos aspectos de la historia de TOPS-20.
Fui estudiante universitario en el MIT de 1961 a 1965. Después de obtener mi título en 1965, comencé a trabajar para BBN realizando varias actividades de programación de sistemas y - en particular - dando soporte al sistema LISP que se usaba por entonces para la investigación de IA (Inteligencia Artificial). Participé en el diseño de TENEX e implementé una serie de módulos en su kernel desde 1968 hasta 1972 y luego desembarque en DEC junto con TENEX en 1973.
En 1973 DEC compró a TENEX, creyendo que representaría una buena base para un nuevo sistema comercial de última generación. Sin embargo, al igual que con otras "sensaciones de la noche a la mañana", este fue solo el paso final en el coqueteo entre DEC y BBN que se prolongaba ya varios años. En 1961, BBN había sido una de las primeras compañis aparte de DEC en instalar y usar la PDP-1 (la primera minicomputadora de DEC), y en ella realizó algunos experimentos fundantes sobre tiempo compartido - usando esta máquina y algunas modificaciones de diseño propio. Se la considera generalmente como el primer sistema de tiempo compartido práctico. A lo largo de los años subsiguientes, se produjeron muchas debates entre ambas empresas sobre la mejor forma de diseñar y construir computadoras.
Una de esas áreas de discusión fue la paginación y la gestión de la memoria. BBN estaba llevando a cabo una serie de proyectos de investigación de IA en lenguaje LISP, y estos generalmente necesitaban una gran cantidad de memoria de acceso aleatorio (RAM). Pocas computadoras de aquel entonces (y ciertamente, ninguna que BBN pudiese pagar) disponían de la cantidad de memoria requerida, por lo que se buscaron una serie de técnicas alternativas para solventar esta limitación [2]. La Paginación y "memoria virtual" fue un área de la ciencia del cómputo en el que hubo mucho interés. En BBN habíamos hecho un sistema LISP que corría en la PDP-1 de BBN, y lo habíamos adaptado para usar un sistema de paginación por software que había sido desarrollado previamente en el MIT.
Este sistema utilizaba un tambor magnético de alta velocidad como almacenamiento de masa para la memoria principal, y segmentaba tanto la memoria principal como la del tambor magnético en unidades de tamaño fijo (llamadas "páginas") que podrían copiarse de un lado a otro según fuese necesario. El sistema LISP en sí usaba punteros de 18 bits y fue construido como si hubiese una memoria de 18 bits (262 KWORDS) en la máquina. Sin embargo, al emplear paginación por software, cada referencia a la ubicación de destino de uno de estos punteros resultó en una llamada a una subrutina (o secuencia en línea). Esta subrutina consideraba los pocos bits de orden superior del puntero como índice en una matriz (una "tabla de páginas") que contenía la ubicación física real de la página. Si la página se encontraba en la memoria principal, los bits del número de página de la tabla reemplazaban a los utilizados como índice en la tabla, y se completaba la referencia de la dirección de memoria. En cambio si la página deseada no se encontraba en la memoria principal, se realizaba una llamada a una rutina de "administración de página" capaz de reorganizar las cosas según fuese necesario. Esto implicaba seleccionar una página en la memoria principal para moverla (copiarla) de regreso al tambor magnético, y tras de ello leer en esta página la referencia a la página deseada en el tambor magnético. Como corolario, se modificaban los registros de esta tabla para reflejar todos estos cambios, y la secuencia de referenciado podría comenzar de nuevo.
En uso real, este manejo resultó bastante efectivo. Los patrones de referencia de los programas LISP que solíamos correr eran tales que el sistema no estaba dominado por esperas de E/S de la pila. Es decir, la mayoría de las referencias de punteros solían ser destinadas a páginas que se encontraban en la memoria principal, y únicamente una pequeña fracción resultaban destinadas a páginas que debía leerse del tambor magnético.
[* - Se han realizado varios estudios, algunos por nosotros mismos en BBN, tendientes a investigar el comportamiento de referencia de la memoria y recopilar estadísticas de varios programas [3].]
Sin embargo, el número real de referencias era lo suficientemente alto como para insumir una gran cantidad de tiempo a la traducción por software de las secuencias de direccionamiento, y nos terminamos dando cuenta que - en última instancia - si deseábamos un sistema de memoria virtual paginado realmente efectivo, esta traducción habría de realizarse a través del uso de hardware dedicado.
La PDP-6 fue anunciada en 1964 y de inmediato resultó la máquina elegida para programar en LISP. Una WORD única capaz de contener dos direcciones (CAR y CDR en términos de LISP) parecía convenientemente diseñada especialmente para LISP (no era una mera coincidencia). El gran espacio de direcciones (para la época) de 2_^18 WORDs prometía rápida ejecución y eficiencia ante los grandes programas LISP. Aunque el conjunto de instrucciones básico no tenía la instrucción CONS (la primitiva LISP que crea listas), una de los primeros PDP-6 contaba con una modificación especial para proporcionar este operando. Esta máquina fue la que estaba instalada en el Laboratorio de IA de la Universidad de Stanford (SAIL), dirigido por uno de los magnos inventores de LISP, John McCarthy.
Nuestro grupo de BBN tenía toda la intención de adquirir una PDP-6 para muscular nuestras capacidades LISP, pero, por supuesto, queríamos que contara con paginación por hardware para poder aplicar las técnicas de paginación que tenía nuestro PDP-1 para LISP. Se llevaron a cabo varias discusiones entre BBN y DEC, incluyendo a Win Hindle y Alan Kotok por parte de DEC. BBN presionó para que incluyeran paginación a una variante nueva de PDP-6, o bien que lo desarrollaran como un complemento opcional, pero esta discusión se desinfló cuando DEC anunció que no sacarían más variantes de la PDP-6, es decir, que DEC abandonaría el negocio de las máquinas de 36 bits. Esta (1966) fue la primera de varias ocasiones como estas.
Tomando la palabra de DEC, BBN centró su atención en seleccionar otra máquina, con suerte una que contase con un futuro de crecimiento, que pudiera usarse para llevar a cabo nuestros diversos proyectos de investigación. El resultado de este proceso de selección fue la compra de una SDS-940. SDS era Scientific Data Systems de El Segundo, California, luego adquirida por Xerox y conocida como XDS. La SDS-940 era una máquina de 24 bits por WORD, con un espacio de direccionamiento virtual modesto, pero que contaba con paginación por hardware. Además, SDS promocionaba ya una heredera, la Sigma-7 - entonces en desarrollo - que sería más grande, más rápida y podría hacerte el café. Si lo haría, nunca lo supimos porque cuando salió, habían anunciado la DEC KA-10 (o al menos "habían lanzado el globo"), y felices y contentos nos dimos a cambiar de nuevo a la arquitectura que realmente queríamos.
También fue un factor a considerar que la Sigma-7 sufrió un retraso en su cronograma de desarrollo. Sí, esto realmente sucedió a pesar de las firmes garantías de SDS de que tal cosa no era sucedería. SDS incluso había publicado varios anuncios en revistas comerciales promocionando su próximo sistema como "el mejor sistema de tiempo compartido que aún no está disponible". Otro anuncio memorable decía "Nos dicen locos por publicar un cronograma firme de desarrollo de software, pero helo aquí". Aparentemente, quien se lo dijo estaba en lo cierto porque el famoso programa firme salió por la misma chimenea de los programas de desarrollo de software "firmes" de todas las épocas...
El anuncio anterior también inspiró a alguien en DEC a crear un anuncio con un contador para TOPS-10 que decía "anunciamos el mejor sistema de tiempo compartido ya disponible".
A pesar de esto BBN usó la SDS-940 durante un par de años y ejecutábamos un sistema operativo desarrollado por un grupo de U.C. Berkeley. Este resultó significativo porque una serie de características en el sistema de tiempo compartido de Berkeley se modificarían y adoptarían posteriormente en TENEX.
Cuando BBN se enteró de que DEC había regresado en secreto al negocio de los 36 bits (o al menos estaba desarrollando una nueva máquina bajo esa arquitectura), presionó una vez más para que se incluyera un sistema de paginación por hardware. Y de nuevo fue en vano. Un avance incorporado al procesador KA-10 fue la protección dual y los registros de reubicación (el PDP-6 contaba con solo un par). Esto permitía que los programas se dividieran en dos segmentos: una "porción reentrante" de solo lectura y un "área de datos" de lecto-escritura. Esto era - sin embargo - lo más lejos que DEC estaba dispuesta a llegar por entonces en el sentido de avanzar su soporte de gestión de memoria para un sistema operativo de última generación.
Otro factor fue la firme intención de DEC de mantener contenido el precio de esta nueva mainframe. A DEC le iba bien con microcomputadoras (en particular, la PDP-5 y PDP-8), pero la mini PDP-6 había sufrido numerosos problemas de ingeniería y confiabilidad, era difícil de vender y - según algunos - casi arruina a la empresa. El KA-10 contaba con una restricción de diseño pensada para permitír configurar y vender una configuración de prestaciones mínimas por menos de 100.000 dólares. Esta configuración base estaba limitada a 16 kWORDS de memoria principal y carecía de registros de estado sólido para los 16 acumuladores (todas las referencias de CA iban a la memoria principal con una penalización considerable en velocidad operativa). Para dar soporte a esta configuración de base, DEC se abocó a diseñar una compilación "mínima" de TOPS-10 que cabría en 8 kwords, y se exprimieron varias utilidades de manera similar: el PIP pasó a tener 1K, etc. Me es difícil decir si el precio mínimo de $99,999 resultó una buena estrategia de marketing. En cualquier caso, nunca vendieron ninguna de esa configuración.
Además, por entonces la paginación y la "memoria virtual" todavía eran conceptos bastante nuevos. Los sistemas comerciales importantes aún no adoptaban estas técnicas, y la idea de pretender contar con más memoria de la que realmente se tenía instalada en placa fue vista con mucho escepticismo en muchos sectores.
Sin desanimarse por la negativa de DEC a considerar la sabiduría de nuestro enfoque, BBN planeó la compra de varios procesadores KA10 y se dispuso a descubrir cómo hacer con ellos el sistema que realmente deseábamos. Además de la arquitectura de 36 bits que preferíamos, el procesador KA10 retenía gran parte de la modularidad inherente del hardware de la PDP-6, en particular lo que hacía al bus de memoria con unidades de almacenamiento independientes. Esto nos llevó a concebir la idea de colocar un dispositivo de mapeo lógico entre el procesador y las memorias que se encargaría de realizar la traducción de direcciones tal como habíamos envisionado.
Otra decisión que tuvimos que tomar fue si intentaríamos modificar TOPS-10 para que admitiese paginación bajo demanda. La alternativa era construir nosotros mismos un sistema nuevo desde cero, empresa ambiciosa incluso en aquellos días. Obviamente, decidimos construirnos un nuevo sistema, sistema que más tarde se llamó TENEX. Esta decisión se justificó en gran medida porque se requeriría una cirugía mayor para adoptar TOPS-10 a nuestras especificaciones, e incluso si nos poníamos en esa tarea, probablemente no hubiésemos podido resolver todos los problemas que aparecerían. En retrospectiva, esta opinión probablemente estaba justificada ya que, si bien el desarrollo de TOPS-10 se extendió durante casi 20 años mas después de que comenzamos con TENEX, al TOPS-10 nunca lo modificaron para incluirle todas las funciones de memoria virtual que tenían TENEX/TOPS-20. TOPS-10 finalmente terminó admitiendo paginación y la memoria virtual, pero no las otras características.
Más allá de eso, había toda una serie de funciones adicionales sin relación con la paginación que queríamos incorporarle al sistema operativo. Esto inclinó aún más la balanza hacia implementar un nuevo sistema. Finalmente, no teníamos el deseo o la capacidad de implementar versiones nuevas de los muchos compiladores y utilidades de lenguaje disponibles en TOPS-10, por lo que necesitábamos un método para ejecutar estas imágenes "tal cual". Decidimos que sería posible emular las llamadas del sistema operativo de TOPS-10 con un módulo separado que traduciría las solicitudes en servicios nativos equivalentes. Esto se describe con más detalle más adelante. Entonces, el plan sería implementar un nuevo sistema desde el nivel de interfaz del sistema operativo hacia abajo, además de sistemas principales particulares como LISP que fueron clave para nuestro trabajo de investigación.
La memoria virtual mediante paginación constituía la necesidad fundamental que llevó a la decisión de construir TENEX. Si TOPS-10 u otro sistema existente hubiese cumplido con ese requisito, probablemente lo habríamos utilizado y no nos hubiésemos abocado a la construcción de un kernel nuevo. Los otros requerimientos no habrían sido tan críticos como para justificar tal esfuerzo y, por supuesto, no previmos todas las capacidades que las que terminaría contando.
El desarrollo de TENEX estuvo motivado en gran medida por las necesidades de varios programas de investigación en BBN, en particular los de Inteligencia Artificial. Estas necesidades resultaban compartidas por varios otros laboratorios apoyados por la Agencia de Proyectos de Investigación Avanzada (ARPA) del Departamento de Defensa, y en el período de 1970 a 1972, varios de ellos empleaban TENEX como base de sus programas de investigación. Como señalé anteriormente, la principal necesidad era disponer de una gran memoria virtual debido a la popularidad y el tamaño de los programas LISP para reconocimiento de voz, procesamiento de imágenes, procesamiento de lenguaje natural y otros proyectos de IA.
Durante este mismo período se estaba tendiendo y colocando en funcionamiento la red ARPA. TENEX fue uno de los primeros sistemas en conectarse a ARPANET y en contar con soporte para la red como una capacidad nativa del sistema. Esto incrementó aún más su popularidad.
Al igual que la mayoría de los sistemas operativos, TENEX resultó una amalgama de ideas de varios orígenes. La mayoría de las características apreciada de TOPS-20 tenían sus raíces en otros sistemas anteriores. Algunos se aplicaron prácticamente sin cambios, ciertas fueron alteradas de forma crítica, y otras sirvieron simplemente como semilla de una idea difícilmente reconocible en el sistema final. Entre las que podemos rastrear desde uno o más sistemas anteriores se encuentran: el "reconocimiento de Escape", la estructura de memoria virtual, su estructura de procesos y sus usos, y técnicas de programación de procesos de tiempo compartido.
Hubieron tres sistemas que afectaron el diseño de TENEX de forma mas directa: MULTICS del MIT, DEC TOPS-10 y el sistema de tiempo compartido de Berkeley para la computadora SDS-940. De todos ellos, MULTICS era el sistema más nuevo, y el más "vanguardista" de la época, e incorporaba últísimas ideas en la estructuración de sistemas operativos. De hecho, se decía en algunos círculos que con la implementación de MULTICS, "el problema del sistema operativo ha sido resuelto". Varios miembros de la facultad y el personal del MIT que habían trabajado en MULTICS brindaron su valiosa visión y comentarios sobre el diseño emergente de nuestro TENEX.
Muchos de los conceptos de paginación provenían de nuestro propio trabajo previo, en particular el sistema LISP para la PDP-1. Otras ideas de reciente eran de aparición en la literatura de sistemas operativos, incluído el modelo de "conjunto de trabajo" de comportamiento de programas de Peter J. Denning [4]. MULTICS había desarrollado el concepto de segmentación y el de mapeo de procesos de archivo; esto consiste en emplear espacio de direccionamiento virtual como una "ventana" para los datos que residen permanentemente en un archivo.
El sistema Berkeley 940 contaba con una estructura multiproceso, con procesos que eran relativamente económicos de crear. Eso, a su vez, permitía cosas tales como un intérprete de lenguaje de comandos de sistema capaz de ejecutarse en modo desprivilegiado, y un depurador que no compartía espacio de direcciones con el programa evaluado, y - por lo tanto - no estaba sujeto a destrucción si un programa se descontrolaba.
Estos dos conceptos (memoria virtual y procesos múltiples) fueron fundamentales para el diseño de TENEX y - en última instancia - fueron clave en la potencia y la flexibilidad de TOPS-20. Las dos abstracciones también funcionaron bien juntas. El concepto de Proceso incluía un espacio de direcciones virtuales de 262 kWORDS (direcciones de 18 bits), el máximo posible según el diseño del conjunto de instrucciones de 36 bits. Aún faltaban muchos años para llegar al direccionamiento extendido, y la posibilidad de que pudiesen necesitarse más de 262k no se le ocurrió a casi nadie.
Simplemente queríamos contar con espacio de direccionado virtual completo para todos los procesos, sin necesidad que el programa en sí estuviese al tanto de la paginación demandada o que tuviese que considerar "volverse virtual". Creíamos que los mecanismos podrían integrarse tanto al hardware de paginación y al sistema operativo a fin de que rastreasen y determinaran los conjuntos de trabajo del proceso, a fin de administrar la memoria de manera tan buena y eficiente como si el fuese el mismo programa quien proporcionaba dicha información de forma explícita (lo que podría ser incorrecto). Por supuesto, podría suceder que un programa particular contase con un conjunto de trabajo demasiado grande para correr de manera eficiente desde la memoria física disponible, pero aún así el sistema haría lo que mejor pudiera, a resultas de lo cual el programa correría dando una paliza al tambor magnético... En cualquier caso, la implementación de la memoria virtual debía ser transparente para los programas de usuario.
Habíamos aprendido que para admitir una memoria virtual paginada por demanda transparente, debíamos mantener cierta información histórica sobre el comportamiento de los programas y el paginado. Esto condujo al diseño e inclusión de la llamada "tabla de estado del núcleo" dentro de la interfaz de paginación por hardware. Otras tablas (es decir, las tablas de las páginas) contendrían información referente a la traducción de direcciones lógicas a físicas; mientras que la tabla de estado central se especificó para contener información relacionada al uso dinámico y el traslado de las páginas. Para cada página física en uso paginado, la tabla de estado central registraba: (1) una marca de tiempo de la última referencia y (2) un identificador de procesos al que habían hecho referencia la página. Este último se incluyó ya que consideramos que habrían muchos procesos haciendo uso compartido de una página determinada. Esta necesidad de compartir también se representó como causal en varios aspectos adicionales del diseño de la paginación[5].
La necesidad percibida de compartir páginas en memoria y las ideas de segmentación que habíamos visto en MULTICS dieron como resultado el diseño de las capacidades de mapeo de archivo a proceso. En el hardware de paginación, esto tenía lugar a través de dos tipos de entradas en las tablas de páginas: "compartidas" e "indirectas" (además del tipo "privado" que contenía un mapeo directo desde virtual a físico). Esto permitía que la dirección física de una página compartida se mantuviera en un único lugar a pesar que la página fuese utilizada en muchos lugares, incluso si el espacio de direcciones de los procesos se intercambiaba. El puntero "indirecto" eventualmente permitía otra capacidad no prevista inicialmente: la capacidad de hacer que dos o más espacios de direcciones de proceso fuesen equivalentes, no solo en lo que respecta a los datos contenidos en ellos, sino también con respecto al mapeo*.
Esto permite, por ejemplo, una operación de "bifurcación" de tipo "tee" de Unix, a fin de crear el espacio de direcciones secundario de forma muy económica, incluso si se reemplaza o no por un intérprete EXEC a posteriori.
Queríamos lograr en el software algunos de los beneficios de la "segmentación" presentes en MULTICS, pero el espacio de direcciones de la PDP-10 no era lo suficientemente grande como para usar el enfoque MULTICS sin mas. Como consecuencia decidimos extender la idea de la memoria con nombre hasta el nivel de página y permitir así que el mapeo fuese realizado página por página. Como resultado estos aspectos se hicieron fundamentales de la arquitectura de memoria virtual presente en TENEX/TOPS-20, específicamente contaba con:
Sabíamos que la mayor parte del intercambio sería de datos de solo lectura, especialmente de texto de programa y datos constantes, pero que cualquier programa podría contener variables inicializadas que eventualmente se escribirían. Más allá de eso, casi todos los datos que normalmente son de solo lectura pueden modificarse en algunas circunstancias, p. inserción de un punto de interrupción para la depuración. En el sistema LISP, grandes cantidades de programas se representaban como estructuras LISP, y el usuario podía editar y modificar estas estructuras.
Por lo tanto, no era aceptable imponer referencias de solo lectura en la mayor parte de este almacenamiento, ni sería eficiente copiarlo cada vez que un proceso lo usara o hiciera referencia a él. Eso anularía gran parte del objetivo de compartir. La solución que ideamos fue la página de "copia sobre escritura". Esto significaba que la página permanecería compartida siempre que solo se le hicieran referencias de lectura o ejecución, pero si un proceso intentaba escribirla, se haría una copia y el mapa del proceso se ajustaría para contener la copia. Esto ocurriría de forma transparente al proceso. La aplicación real de solo lectura estaba disponible, por supuesto, y el contenido real del archivo (por ejemplo, de un archivo ejecutable del programa del sistema) estaba debidamente protegido contra modificaciones, pero el usuario podía asignar cualquiera de esas páginas de copia en escritura, y una referencia de escritura sería entonces simplemente resultará en el uso de una copia modificada.
Se puede decir que MUTLICS contribuyó con algo más que las ideas para la organización de la memoria virtual y otras capacidades específicas. Durante el diseño de TENEX, invitamos a algunos de los diseñadores e implementadores de MULTICS para revisar nuestro progreso y decisiones. Como suele suceder, habíamos caído en la trampa de tratar de hacer demasiado en varias áreas y habíamos diseñado soluciones bastante intrincadas y complejas. Varias personas de Multics nos criticaron en esas ocasiones, diciendo "esto es demasiado complicado, ¡simplifíquenlo! ¡Descarten esto! ¡Deshazte de eso!" Seguimos gran parte de ese consejo (y probablemente podríamos haber tomado más), y doy crédito a estas revisiones por hacer que las capacidades básicas sean significativamente más fáciles de entender y programar, así como de implementar y depurar.
Esta fue una de las primeras ocasiones en las que realmente comencé a apreciar el hecho de que un diseño complejo y complicado para implementar en un producto de software o hardware no es indicio de gran habilidad o madurez por parte del diseñador. Más bien, suele evidenciar falta de madurez, perspicacia, comprensión de los costos de la complejidad y de visión del problema en su contexto más amplio.
El tiempo transcurrido desde que se escribió la primera entrada de código fuente en TENEX hasta que fue funcional y sirviendo a usuarios regulares fue de aproximadamente seis meses, notable incluso para esa época. Por entonces era un sistema lejos de estar completado, pero los internos de BBN ya lo usaban con efectividad.
Una de las cosas que contribuyó a tan rápido desarrollo fue nuestra preocupación por el soporte de depuración. DDT era el depurador simbólico estándar de la PDP-10 y había sido escrito a partir de versiones anteriores de la PDP-6, PDP-1 y la TX-0 (máquina experimental del MIT preserie de la PDP-1). DDT era poderoso para su época, e incluso hoy en día sigue siendo elegido por los usuarios más experimentados a pesar de la existencia de sistemas de depuración orientados a pantallas y ventanas. En TOPS-10, DDT se ejecutaba tanto en modo ejecutivo (núcleo kernel) o en modo usuario, por lo que admitimos ambos modos en TENEX también.
Proporcionamos además una forma que DDT se ejecutase a tiempo compartido mientras revisabas el código fuente del sistema y las estructuras de datos. Esto permitía que varios desarrolladores depuraran el código del sistema al mismo tiempo, al menos hasta cierto punto. Incluso podían manejarse los puntos de interrupción, siempre que ningún otro proceso corriese el código mientras el punto de interrupción estaba en su lugar. DDT tenía el conjunto completo de símbolos y la escritura de valores numéricos disponibles en todos los modos, por lo que podías depurar sin una tener a mano una referencia constante de los listados.
En modo usuario, podías encadenar DDT a cualquier programa incluso si ya estaba en ejecución. En los sistemas anteriores debían anticiparse la vinculación del depurador con el programa ejecutable. En TENEX, cuando era necesario simplemente podía mapearse DDT en una dirección alta libre dentro del espacio de direcciones que estuviese alejada de los bloques empleados por la mayoría de los programas. Una versión aún más poderosa de DDT llamada IDDT (por invisible) corría en un proceso separado del programa en depuración. Por lo tanto, era inmune a corrupciiones de memoria del programa a prueba, y podía interceptar así todas y cada una de las acciones ilegales. Desafortunadamente, esta versión de DDT divergió de la rama principal de DEC DDT, e IDDT jamás se actualizó o convirtió en el depurador normal (incluso de TOPS-20). No obstante, este uso simplificado y potente de DDT hacía que la programación fuese mucho más efectiva, tanto para los usuarios como para los programadores de sistemas.
Otra área en la que TENEX - y más tarde TOPS-20 - se destacaban fue en su interfaz de usuario, que describo en detalle a continuación. Una razón clave por la que pudimos ampliar la interfaz de usuario de manera tan significativa fue que el código fuente que la implementó corría como un programa de usuario común. No estaba limitado por tanto en tamaño ni por funciones que no se podían realizar en modo kernel. Más allá de eso, la depuración era mucho más simple: no requería el uso de máquinas independientes como lo hizo la depuración del kernel. Todo esto avalaba gran cantidad de experimentaciones y evoluciones como resultado del ajuste y retroalimentación por uso real de usuarios reales.
Parte de la "filosofía" de diseño de sistemas surgió en la propia BBN y entre algunos de los institutos de investigación de ARPA, e iba a tener un gran impacto en la sensación general de TENEX y - en última instancia - en TOPS-20. En aquél entonces lo llamamos "ingeniería humana": queríamos que el sistema fuese fácil de aprender y usar, y queríamos que el sistema se ocupara lo mejor posible de la tarea sucia para que el programador o el usuario no tuviese que lidiar con ella. Estábamos dispuestos a gastar ciclos de máquina reales y memoria real (o al menos virtual) para que esto sucediera.
Esta filosofía condujo inicialmente a las funciones de interfaz humana de EXEC, incluyendo su "reconocimiento de Escape", la función de ayuda con el signo de interrogación, los subcomandos opcionales y las palabras de "ruido". Pocas personas ahora argumentan contra la necesidad de proporcionar interfaces humanas efectivas, pero en aquél entonces tuvimos muchos detractores que percibían que era una pérdida de ciclos ofrecer un reconocimiento de comandos. Este tipo de funciones - decían - "ralentizarían el sistema" y evitarían que se hiciera un "trabajo útil". Otros sistemas de momento usaban comandos cortos, a menudo de una única letra, o usaban argumentos de comando sin proporcionar ayuda en línea, y no daban respuesta alguna al usuario aparte de la "acción" (si es que la había) de comando que se había ingresado.
Muchos de estos sistemas eran categorizados "por expertos, para expertos". Es decir, estaban programados por expertos y destinados a ser utilizados por otros expertos. Obviamente, un "experto" no necesitaba funciones frívolas, palabras irrelevantes o reconocimiento de comandos. Los expertos conocían no solo todos los comandos, sino también todas las abreviaturas legales. Los expertos supuestamente leían el manual una vez, y recordaban siempre todo lo necesario para interactuar con el sistema. Esas eran las suposiciones implícitas sobre los usuarios: o eras un experto, o eras un ser inferior que no tenias realmente derecho alguno de usar la computadora.
El equipo de TENEX opinaba diferente. Estaba claro que el poder de las computadoras aumentaría cada año, por lo que debía esperarse que la computadora hiciera cosas cada vez mas interesantes. La mayoría está de acuerdo en que uno de los propósitos principales de la automatización informática es liberarnos de tareas aburridas y repetitivas; creíamos que ese propósito también aplicaba al desarrollo de sistemas informáticos, y que era incorrecto exigir que una persona aprendiera un nuevo conjunto de tareas arcanas y aburridas para poder usar un ordenador. La máquina debe adaptarse al hombre, y no el hombre a la máquina.
Esta opinión probablemente se vio reforzada por la investigación de inteligencia artificial que se llevaba a cabo en el entorno donde se diseñaba TENEX. En las áreas del reconocimiento de voz, reconocimiento de patrones y la comprensión de lenguaje natural se aplicaba un poder de cómputo masivo que las computadoras interactuasen de forma más humanas. Estos eran esfuerzos a largo plazo, pero también queríamos que nuestros sistemas informáticos estuvieran más orientados a los humanos.
Una de las ideas que surgieron de la investigación de la IA fue que la computadora debería estaar programada para "hacer lo que quiero decir", incluso si no lo dije del todo bien o tal vez cometí un error de ortografía. Warren Teitelman implementó funcionalidades avanzadas en LISP que corrigiesen errores automáticamente o con una intervención mínima del usuario, y esto se denominó paquete DWIM. Con este tipo de esfuerzo de investigación en curso, estábamos convencidos de las restricciones y torpezas presentes en la mayoría de los sistemas existentes.
Por lo tanto, tomamos decisiones - hoy obvias - como (1) identificar a los usuarios por nombre alfanumérico en lugar de número; (2) permitir que los nombres de los archivos fuesen lo suficientemente largos para representar información significativa (para el ser humano); (3) escribir o presentar una confirmación positiva de las acciones solicitadas por el usuario; (4) permitir ciertas gamas de preferencias individuales para los usuarios con respecto al estilo de entrada y salida de comandos.
Buscamos específicamente formas de interacción que parecieran naturales cuando juzgándolas desde una perspectiva interpersonal. Si asumimos esa base, muchos comportamientos típicos de la interfaz computada resultan hostiles. En interacción interpersonal, las respuestas crípticas, no concisas y/o abruptas; sintaxis de entrada inflexible y oscura; el uso de palabras con significados contraintuitivos se consideran groseros o aún peor.
Este deseo de hacer que la computadora hiciese el trabajo sucio también motivó el diseño en otros ejes. La paginación bajo demanda y la memoria virtual se consideraron formas de reducir la carga y dificultad de escribir programas grandes. Al disponer de una gran memoria virtual, el programador no tendría que preocuparse por la segmentación o superposición de memoria en su programa. Más bien, dejaría que el sistema se encargaase de la gestión de memoria y el podría concentrarse en los detalles de la trabajo en cuestión. Otras funciones (como la estructura del proceso, las llamadas a las utilidades del sistema y el análisis de archivos estandarizado), tenían como objetivo facilitar el trabajo de programación del sistema al proporcionar funciones estándar y potentes al programador.
Una de las características mejor recordadas entre los usuarios de TOPS-20 (y una de las más identificadas con el propio TOPS-20), fue el "reconocimiento de escape". Con él el usuario a menudo podía hacer que el sistema, en efecto, autocompletase por él la mayor parte de un comando o nombre simbólico. La función es más fácil de usar que de describir; sin embargo, a continuación se presenta una breve descripción para ayudar a comprender su desarrollo.
Presionar la tecla de Escape le dice al sistema: "si sabe lo que quiero decir con lo que he tecleado hasta este punto, escriba lo que viene a continuación como si lo hubiera escrito yo mismo". Lo que se muestra en la pantalla o se autocompleta tiene el aspecto como si el usuario lo hubiese escrito, pero por supuesto, el sistema lo realiza mucho más velozmente. Por ejemplo, si el usuario escribe DIR y escapa, el sistema continuará la línea para que se lea DIRECTORY.
TOPS-20 aceptaba también solo la abreviatura DIR (sin escape), y si un usuario experto quería ingresar el comando en forma abreviada podía hacerlo sin demora. Para el usuario novato, escribir escape tenía varios propósitos:
DIRECTORY (OF FILES)
Esto indicaba que los archivos estban siendo tratados con ese comando y que podía indicarse un fichero como siguiente entrada. Si un comando contaba con varios parámetros podía recurrirse a esta interacción varias veces. Se demostró claramente en este y otros entornos que la interacción frecuente y la retroalimentación son muy beneficiosas para darle al usuario confianza de que va por el camino correcto y que la computadora no está tendiéndole una una trampa terrible. Si bien puede llevar un poco más de tiempo ingresar un comando de estas características a diferencia de lo que haría un usuario experto con abreviaturas crítpticas, lo cierto es que este costo es pequeño en comparación con la penalización de ingresar erroneamente el comando. Un comando incorrecto significa que al menos se ha desperdiciado tiempo en escribir erróneamente la línea de comando. Pero si da como resultado seguir una acción errónea (en vez de no hacer nado), el costo puede ser mucho mayor.
Esta es una razón subyacente clave por la cual la interfaz TOPS-20 era considerada amigable: reducía significativamente la cantidad de eventos grandes de retroalimentación de carácter negativo que le ocurrían al usuario y en su lugar proporcionaba muchas más interacciones pequeñas pero de carácter positivas (es decir, exitosas). Este refuerzo positivo parecería forzado en términos interpersonales, pero a lo largo de la mayor parte de la historia de las computadoras, hemos ignorado la necesidad del usuario humano de que la computadora sea también un miembro positivo y alentador del diálogo humano-máquina.
Presionar Escape signfica únicamente una solicitud. Si lo ingresado hasta el momento era ambiguo, el sistema simplemente emitía una señal (un campanazo o pitido) y esperaba nuevas órdenes. Por demás, el reconocimiento de Escape se hallaba disponible para nombres simbólicos (por ejemplo, archivos), y verbos de comando. Esto significaba que el usuario podía usar nombres de archivo largos y descriptivos para asistir en una búsqueda de lo que contienen los archivos, sin tener que escribir estos nombres largos en cada referencia. Por ejemplo, si mi directorio contiene:
MUY_GRANDE_CODIGO MUY_LARGO_TEXTO
Solo necesito escribir G o L para identificar sin ambigüedades uno de esos archivos. Ingresarle letras extra posteriores al inicio del nombre también sirve, de modo que no era necesario recordar abreviaturas mínima; se podía escribir DISPLAY y ver si el sistema reconoce el archivo.
Finalmente, si el usuario seguía inseguro sobre la entrada que venía a continuación de un comando, escribía un signo de interrogación y el sistema proporcionaba una lista de opciones legales en dicha instancia. La lista incluía palabras clave específicas (p. ej., FILE, DIRECTORY) y descripciones genéricas (p. ej., "input file"). Es importante decier que la solicitud del signo de interrogación no destruía la entrada del comando previo. Una vez presentada la lista de alternativas, se volvía a presentar el comando parcial y la entrada continuaba desde el punto justo antes de que el usuario hubiese escrito el signo de interrogación.
Como resultado de esta función:
Conforme se han hecho más comunes las interfaces orientadas a menús, esta ventaja de tener todas las opciones visibles para el usuario se volvió obvia. La función de ayuda con el ? puede considerarse entonces como un "menú personalizado" que funcionaba incluso en terminales demasiado lentas como para admitir completas interfaces basadas en menús.
El sistema de tiempo compartido de Berkeley para el SDS-940 contaba con una forma de reconocimiento antecesora. Sin embargo, no usaba Escape. En dicho sistema, el reconocimiento se presentaba automáticamente; cada vez que el usuario escribía lo suficiente para identificar sin ambigüedades un comando o un nombre simbólico, el sistema cobraba vida y autocompletaba el resto. En el caso ideal esto provocaba que el tecleo fuese mínimo, pero tenía un problema importante y - en última instancia - gravísimo: si el usuario escribía demasiado en un campo (es decir, más de lo necesario para que el sistema reconociese dicho campo), la entrada rebalsaba al siguiente campo donde no estaba prevista. Por ejemplo, el sistema reconocería COP como suficiente para COPY y proporcionaría la "Y". Pero si escribieras el verbo completo, obtendrías:
En tal caso al menos debería borrarse luego la "Y" adicional. Pero si no se advertía lo que sucedido y continuaba escribiendo el resto del comando, lo que pretendía era:
Sería autocorregido como:
Esto al menos produciría un error, y en el peor de los casos podría causar daños importantes. [En el ejemplo anterior, tenga en cuenta que el nombre de archivo anterior termina en el campo de parámetro de archivo nuevo.]
Con experiencia, los usuarios llegarían a reconocer las abreviaturas reservadas y, por lo tanto, rara vez caerían en la trampa ejemplificada. Sin embargo, este reconocimiento automático también funcionaba en en directorios de archivos, y allí, la abreviatura mínima podía cambiar de minuto a minuto a medida que se agregaban y eliminaban archivos. Por lo tanto, incluso un usuario experimentado tendría que teclear con sumo cuidado. Llamativamente este sistema favorecía a los mecanógrafos lentos que se beneficiaban de tener que escribir la cantidad mínima de entrada, pero constituía una frustración enorme para los mecanógrafos rápidos que solían superaban el sistema. Y cuando el sistema se sobrecargaba y la respuesta presentaba retrasos, el desastre resultó absoluto.
Esta experiencia nos convenció de evitar este tipo de reconocimiento automático en TENEX. Pasamos mucho tiempo pensando maneras de resolver el problema de "sobrescribir", incluidas reglas como "si existe una entrada adicional y coincide con la última palabra clave después del punto de reconocimiento, aplíquele esto", etc., pero finalmente no pudimos dar con ningún método que no dejara abierta grandes errores dependientes del tiempo. Consideramos un modo que habilitara o deshabilitara el reconocimiento automático, pero decidimos que no resolvía el problema de la función.
Fue por tal motivo que decidimos hacer que el reconocimiento sucediera solo a pedido explícito, aunque esto requeriese una pulsación de tecla adicional. Y para este propósito elegimos la tecla Escape.
En general, nos abocamos a evitar los modos. Creíamos que definir modo "experto", "principiante", etc. era ignorar el hecho que una persona puede ser novata y experta al mismo tiempo, o puede preferir opciones que no se ajustan a ninguna de estas definiciones. Es probable que incluso un usuario experimentado no esté familiarizado (y por lo tanto sea un "novato") con algunas partes del sistema, comandos, etc., y desearía recibir indicaciones completas al trabaje en dichas áreas. Con el tiempo, observamos que algunos usuarios muy experimentados continuaban usando las ayudas de forma amplia debido a la retroalimentación positiva que proporcionaban.
Viendo en retrospectiva, parecen que las circunstancias bajo las cuales TENEX se mudó a DEC y se convirtió en TOPS-20 pueden haber incluido una serie de eventos fortuitos. Como se señaló anteriormente, en 1972, TENEX había alcanzado cierta popularidad entre los investigadores de la Red ARPA. La renacida máquina de 36 bits, recién bautizada como DECsystem-10, también disfrutaba de un éxito razonable en varios mercados. Sin embargo, valía la pena publicitar el prestigio de ser la elección entre los investigadores de vanguardia, por lo que DEC decidió publicar un anuncio en varias revistas comerciales titulado "ARPA tiene una red de supercomputadoras", señalando que una gran fracción de ellas eran DECsystem-10. De hecho, la mayoría de ellas corrían TENEX. Para abril de 1972, habían siete institutos además de BBN que corrían TENEX.
BBN tenía un negocio modesto construyendo el hardware de paginación de terceros que, con la tecnología de entonces, requería un gabinete de lógica de dos metros de alto por 35 centímetros de ancho. A la par de esto, DEC había comenzado a trabajar en una máquina sucesora que se conocería como KI10 (la "I" sugiere al menos la tecnología de circuitos integrados que se iban a utilizar). Ya en junio de 1970, se llevaron a cabo reuniones en las que la gente de BBN intentó persuadir a DEC para que incluyera hardware de paginación similar al diseño del BBN Pager. Eventualmente, DEC decidió incluir paginación en el KI10, pero basándol en una arquitectura mucho más simple. Los ingenieros de DEC no estaban convencidos de que las distintas formas de punteros (privados, compartidos, indirectos) y la tabla de estado del núcleo redituarían la cantidad de hardware requerido para implementarlas. No obstante, eligieron el mismo tamaño de página, 512 WORDs, lo que al menos dejó abierta la puerta a algún tipo de acomodación posterior.
Cuando salió el procesador KI10, DEC estaba decepcionada (por decir lo menos) por la falta de interés alcanzado entre la comunidad de investigadores que había ayudado a impulsar las ventas del KA10 original. El problema era que la máquina nueva no andaba con TENEX. Si bien era casi el doble de rápido que el KA10, la implementación de la paginación era diferente a la demandada por TENEX. También se hizo demasiado evidente que no sería práctico modificar la estructura de TENEX para utilizar esta paginación limitada del KI10. Como ironía adicional, la versión de TOPS-10 enviada inicialmente con el KI10 usaba el hardware de paginación solo para emular hardware de protección y reubicación del KA10, y no sacaba beneficio alguno de él.
Durante el verano de 1972, había decidido buscar nuevas oportunidades fuera de BBN. Como era de esperar, una de las empresas con la que tenía contacto fue con DEC. En el curso de esas negociaciones, inquirieron sobre la posibilidad de correr TENEX en el KI10. Este no era un deseo generalizado dentro de DEC en general, o dentro de la ingeniería de software de DEC en particular, pero le interesaba especialmente a Allan Titcomb, quien era el gerente de marketing para mercado científico y de investigación. Titcomb ardía de ganas de vender algunos KI10 a los institutos que usaban TENEX.
El resultado de esto fue que fui a trabajar para DEC, como subcontratado. Me hicieron un contrato por un tiempo fijo (3 meses) y precio fijo en DEC para hacer que TENEX funcionara en su KI10[6]. Claramente, los procesos internos de DEC no deseaban dar rienda a un proyecto real en torno a TENEX por entonces, pero un contrato de 3 meses de un solo hombre debe haberles parecido un riesgo pequeño y aceptable.
También recibí una oferta para unirme a DEC como empleado regular después de que terminara el contrato. Sin embargo, inicialmente no se pretendía que este trabajo permanente tuviera una participación continua con TENEX. De hecho, fue para trabajar en el grupo TOPS-10.
Mi contrato para hacer el KI-TENEX se negoció a través del departamento de ingeniería de software de DEC, dirigido en ese momento por Dave Stone, a quien conocía anteriormente. Durante la última parte de las discusiones del contrato, Dave le pidió a alguien más que consultara sobre los aspectos técnicos de mi método propuesto para manejar los diferentes hardware de paginación en el KI10. Resultó ser Peter Hurley, quien por entonces realizaba proyectos especiales de ingeniería de software como parte del grupo de marketing encabezado por Allan Titcomb, lo que marca la primera participación prolongada de Peter en lo que hace a TOPS-20.
Fue entonces, a principios de octubre de 1972, cuando me despedí de BBN y me instalé en una oficina en el 3-5 (edificio 3, piso 5) de los edificios originales de DEC en Maynard. Como era aún bastante joven, la perspectiva de tener un contrato unipersonal de precio fijo y con 3 meses para migrar un sistema operativo a un procesador base de una nueva familia no me pareció particularmente aterradora.
Como parte de mi despedida de BBN, un par de compañeros que habían trabajado anteriormente en DEC me trajeron regalos de despedida que - me aseguraron - me serían muy útiles en DEC: una paleta matamoscas y una lata de repelente de insectos. Por entonces las instalaciones de DEC carecían de la uniformidad aséptica que generalmente se asocia con las oficinas y laboratorios de alta tecnología. Debido a su antigüedad, historia de molino algodonero y a proximidad a un estanque y un río, los edificios estaban bien provistos de varios insectos y arañas, y mis amigos de BBN querían asegurarse de que yo supiera en lo que me estaba metiendo. En última instancia, pasé solo poco más de un año trabajando en los edificios de la fábrica de Maynard, pero hubo numerosas ocasiones a últimas horas de la tarde en las que era nula la posibilidad de concentrarse mayormente en el código fuente; me encontraba observando detenidamente cómo una araña particularmente habilidosa tejía un red circular casi perfecta entre las publicaciones de mi repartición.
La técnica que se me ocurrió para tratar con el paginador simplificado del KI10 no implicaba alterar de forma importante la estructura de paginación de TENEX. Más bien, la idea era emular la mayor parte de la lógica del BBN Pager por software y usar una tabla de páginas del KI10 únicamente como caché de software o búfer de traducción para las asignaciones de páginas virtualizadas a físicas reales. Consecuentemente, esto resultó muy parecido al diseño que se utilizaría en muchos procesadores posteriores donde la lógica se lleva a cabo en microcódigo y el almacenamiento se da en RAM.
La implementación del código PDP-10 para simular el BBN Pager no fue una tarea grande ni difícil y probablemente ocupó menos de la mitad del tiempo del proyecto. Junto con la paginación, era necesario escribir controladores para los dispositivos de archivado e intercambio que luego se enviaba a DEC, ninguno de los cuales se había utilizado en BBN. Sin embargo, el depurado de TENEX en el KI10 dio con un nuevo error de lógica, bastante oscuro, localizado en el hardware de paginación.
Mucho antes del final del período de contrato de tres meses, TENEX ya funcionaba lo suficientemente bien en el KI10 como para servir de base para la compilación de nuevas versiones de sí mismo. Durante este período, utilizamos el sistema en una máquina en el sótano de la planta durante varias horas todos los días, y algunos empleados curiosos se apersonaron para probarlo. Una de estos individuos fue Dave Braithwaite, por entonces perteneciente al grupo de referencia -10, quien trajo a colación varios puntos de vista y pruebas de evaluación.
El contrato finalizó nominalmente (exitosamente) cuando entregué el juego oficial de cintas magnéticas que contenía el código fuente de TENEX y un sistema de arranque en el momento estipulado en el contrato. Sin embargo, esto fue una consideración académica temporal, ya que de manera alguna sería este el final de mi actividad relacionada con TENEX en DEC.
Durante el tiempo que trabajé en KI-TENEX, se hallaba en desarrollo activo el procesador KL10 en el departamento de ingeniería de hardware. La "L" en KL10 originalmente tenía la intención de significar "bajo costo", ya que el KI10 era percibido como caro. Sin embargo, la nueva tecnología brindaba la oportunidad de dar un salto significativo en rendimiento y - en última instancia - esta sería la característica más destacada del KL10. Los gerentes del departamento de línea de productos veían oportunidades de crecimiento en la alta gama, por lo que prepararon el escenario para considerar algunos cambios importantes en las capacidades.
Casi al mismo tiempo, progresaba el proyecto "Super Foonly" dentro del laboratorio de IA de Stanford. Los diseñadores de Foonly proyectaban un factor de aceleración de 10 sobre el KA10 original, e invitaron a los ingenieros de DEC a revisar estos planes. Ciertas ideas, como la división funcional de E-box y M-box, resultaron fundamentales en el diseño definitivo del KL10.
Stanford no era el único lugar donde se diseñaba y construía otra máquina con arquitectura PDP-10. El recientemente inaugurado Xerox PARC (Centro de Investigación de Palo Alto) incorporaba ahora a varios miembros de BBN y otros institutos familiarizados con TENEX, y se hallaban sumamente interesados en continuar desarrollando dicho sistema. Dado que Xerox se encontraba inmersa por entonces en el negocio de las computadoras, PARC no podía adquirirle una PDP-10 a DEC. En consecuencia, se abocaron a construir la suya propia. Se trataba de una máquina de un solo procesador compatible con la paginación KA10 y BBN, al que diseñaron y montaron relativamente rápido. Funcionó con TENEX durante varios años.
Muy posiblemente, el evento fortuito final que selló la decisión de DEC de usar a TENEX como base para un producto propio DEC no se llevó a cabo en DEC sino en IBM. Fue en este momento a finales de 1972 cuando IBM anunció sus sistemas de "memoria virtual" para su familia 360. Si bien esto no fue del todo inesperado, lo cierto es que "legitimó" finalmente el concepto de memoria virtual en los productos de sistemas informáticos. Yo (y otros defensores de TENEX) habíamos promovido activamente las capacidades de memoria virtual de TENEX, pero se juzgó necesario que IBM lo anunciara para demostrar que dichas características podrían convertirse en un factor importante para los grandes mercados de sistemas de cómputo. Esto es bastante irónico ya que las arquitecturas de gestión de memoria de TENEX/TOPS-20 y la de los sistemas de IBM eran bastante diferentes.
Pronto, se llevaron a cabo discusiones en torno a la idea de que el KL10 sería - ya no una nueva CPU para el DECsystem-10 existente - sino la piedra angular de una nueva familia de productos de Memoria Virtual que incluía arquitecturas por hardware por software. Las salidas de la arquitectura de hardware debían contar con memoria principal interna (a diferencia de la memoria de bus externa como en KA y KI), interconexión Massbus para cintas y discos magnéticos, y usaría una PDP 11/40 como consola de sistema. El software daría un paso comparable a las capacidades de TENEX: contaría con memoria virtual, estructura de procesos, y lenguaje de comandos fácil de usar.
Aunque solo fui parte de algunas de esas discusiones, todavía puedo observar con asombro por la velocidad y la confianza con la que se tomó la decisión de emprender un cambio tan radical. Las personas clave incluyeron a Allan Titcomb (quien había iniciado el proyecto KI-TENEX), Fred Wilhelm (director de ingeniería del proyecto KL10), Bill Kiesewetter (director de marketing de la línea de productos DECsystem-10), y John Leng (director de la línea de productos). No convocamos grupos de trabajo ni comités de estudio ni divagamos durante uno o dos años encima de la idea. Nos reunimos, consideramos los problemas y decidimos.
Por ello, concluído el contrato KI-TENEX por tres meses, recibí una segunda oferta de DEC: unirme al grupo KL10 como líder de proyecto para desarrollar un nuevo sistema operativo para el KL10 basado en el TENEX. A mi comienzo de trabajo como empleado de DEC el 2 de enero de 1973, se había contratado a un ingeniero adicional para formar el núcleo de un grupo de desarrollo: Peter Hurley. Ambos establecimos oficinas en el quinto piso del edificio 5 de la planta de Maynard, en grupo con los ingenieros de hardware, la gente de administración y marketing de la línea de productos, y el vicepresidente Win Hindle.
Hubo una serie de áreas en las que sentimos que era necesario trabajar en TENEX para que fuese adecuado para su lanzamiento como producto. Algunas de estas eran áreas en las que TOPS-10 había recibido un trabajo significativo durante los años anteriores, y otras involucraban la mantenibilidad general, el soporte de confiabilidad y servicio de mantenimiento de hardware y la solidez general. TENEX carecía, por el momento, de funciones tales como la operación por lotes o estructuras de disco montables.
También planeamos aumentar significativamente el soporte de "compatibilidad con TOPS-10": la capacidad del sistema para admitir programas y medios TOPS-10 ya existentes. Este soporte tomó varias formas: la interfaz de llamada de servicio del sistema operativo, el lenguaje de comandos, los formatos de estructura de disco y otras interfaces externas. TENEX contaba con disposiciones que sólo hacían a la interfaz de llamadas del sistema operativo, y era limitado por el desconocimiento por parte de BBN de ciertos detalles y aspectos no documentados de las llamadas TOPS-10. Además, la compatibilidad de la interfaz de llamadas resultaba solamente lo suficientemente completa como para que BBN pudiese correr un conjunto particular de software en las capas TOPS-10, y no mucho más.
Una de las razones para buscar las funciones de compatibilidad con TOPS-10 fue la posibilidad de convergir nuevamente en un sistema operativo para todas las máquinas de 36 bits. Sin embargo, esta idea fue y siguirá siendo controvertida: el destino de estas características es en gran medida el resultado de una continua indecisión sobre cuánto esfuerzo destinar a las herramientas de ayuda para los usuarios que migran de TOPS-10 a TOPS-20.
A veces, se hacía clara la intención que TOPS-20 eventualmente se convirtiera en el único sistema operativo de 36 bits. Parecía contar con la capacidad para admitir cualquier nivel deseado de retrocompatibilidad con TOPS-10 y nos ofrecía características de TOPS-10 solicitadas por los clientes, pero que parecía poco probable que se pudieran realizar en TOPS-10. Sin embargo, la mayoría de las veces, a corto plazo parecían que TOPS-10 (y sus mejoras) continuaban siendo necesarios si deseábamos conservar una parte del mercado de 36 bits. Por todo esto la línea de productos en su conjunto jamás pudo lograr una determinación definitiva para mover la idea de un negocio alrededor de un único sistema operativo.
En los inicios de la era del DECSYSTEM-20, la gente de línea de productos hizo algunas propuestas a los clientes del DECSystem-10 para migrar al -20. Pero por entonces no estaban disponibles aún las ayudas de migración, el TOPS-20 carecía aún de todas las capacidades necesarias y los clientes del -10 no estaban dispuestos a aceptar los límites de configuraciones que tenñia el -20. Motivo por el cual los clientes reaccionaron bastante negativamente y terminaron asustando a línea de productos para que no hiciese nada que sugiriera una estrategia de migración.
En última instancia, ambos sistemas operativos continuaron desarrollándose y distribuyéndose en paralelo hasta que la corporación tomó la decisión mucho más drástica: dejar ofrecer nuevos productos de hardware de 36 bits y reducir todo desarrollo de software para 36 bits. Por estas y otras razones, nunca fue prioridad reemplazar el viejo TOPS-10 durante la vida del DECSYSTEM-20 y, por tanto, no se consideró importante incluirle a TOPS-20 las funcionalidades como el lenguaje de comando de TOPS-10. Los altibajos subsiguientes en el interés para volver a converger en un sistema operativo único se describirán más adelante.
Dentro de la estructura de TENEX nos había sido posible implementar una compatibilidad con la interfaz de llamadas TOPS-10 de manera relativamente modular. Esta conjunto de software se llamó PA1050 (en honor al sistema DEC 10/50, que era el mejor de la línea -10 en ese momento). A fin de admitir las interfaces de llamada del sistema operativo antiguo (TOPS-10) y nuevo (TENEX), decidimos utilizar un mecanismo de llamada nativo completamente diferente al empleado en TOPS-10. TOPS-10 usaba MONITOR UUO, un grupo de instrucciones que transferían el control al kernel por medio de un vector de transferencia. TENEX tomaba un código de operación previamente no asignado (el octal 104) y le daba el mnemónico JSYS (de Salto a Sistema). (El sistema Berekely 940 había utilizado un nemónico BRS, Branch to System, o Rama de Sistema).
En TENEX, cualquiera de las llamadas de servicio en ejecución de TOPS-10 era dirigida a una pequeña parte del código del kernel que invocanba al PA1050. En la primera llamada de este tipo, se asignaba la imagen PA1050 a un área alta de la memoria virtual de usuario y se le transfería el control. En las llamadas posteriores, se limitaba a efectuar transferencias. Por lo tanto, solo aquellos procesos que realmente hicieron llamadas TOPS-10 recibían el código compatible, y cada uno de tales procesos tendría su propia encarnación. La implementación de memoria virtual de TENEX resultaba en que el código o los datos se podrían colocar en cualquier lugar y no había penalización por uso escaso del espacio de direcciones. Por entonces, era bastante seguro usurpar un rango de direcciones altas de un programa TOPS-10, ya que usar tales direcciones en un sistema TOPS-10 real (sin memoria virtual) hubiese requerido las 256 kWORDS completas de memoria o más para correr. Más tarde, conforme los programas de TOPS-10 se fueron hiciendo más grandes, se presentaron problemas para comprimir unificadamente el programa junto a la rutina PA1050 y el DDT (que también tenía asignado un rango alto en las direcciones de memorias).
PA1050, por entonces, era simplemente un código fuente que corría en modo de usuario sin privilegios. Cuendo era necesario, interceptaba e interpretaba los argumentos de la llamada TOPS-10 y realizaba la acción solicitado haciendo uso de llamadas JSYS de salto al sistema. Mantenía a tal fin una base de datos propia sobre el estado del trabajo de emulación TOPS-10 en la memoria del proceso local.
Una de las características atractivas de TENEX fue la idea de lenguajes de comando alternativos. El lenguaje de comandos TENEX (el "EXEC") era simplemente un programa en modo de usuario que operaba dentro de un proceso, encargado de realizar cualquier acción del sistema a través de llamadas JSYS definidas. Por tanto, cualquier usuario podía escribir y ejecutar de la misma manera un programa similar para se ejecutara en cualquier otra interfaz deseada sin afectar a otros usuarios en el mismo sistema. La gente de marketing se hizo la visión de ofrecer interfaces compatibles con varios entornos de la competencia para atraer clientes de tales sistemas. También imaginamos escribir una interfaz de usuario que se parecería al lenguaje de comandos TOPS-10 para facilitar la migración de usuarios de TOPS-10.
De hecho, un tercer miembro del grupo del nuevo sistema - Arnold Miller - escribió dicho programa durante el primer año de desarrollo en DEC. Esta interfaz funcionaba lo suficientemente bien como para admitir la ejecución de archivos por lotes TOPS-10, así como la mayoría de las actividades normales del usuario. Sin embargo, nunca se envió como parte de TOPS-20, en gran parte porque los usuarios que venían a TOPS-20 desde TOPS-10 o cualquier otro sistema empezaron a usar y preferir rápidamente el nuevo lenguaje de comandos TOPS-20. Incluso entre aquellos usuarios reacios a probar lo diferente, las ventajas del EXEC del TOPS-20 Exec se volvieron tan envidentes, que pocos quisieron continuar operando con su antiguo entorno. Por tal motivo, finalmente jamás escribimos otras interfaces capaces de imitar los sistemas de la competencia.
Sin embargo, en una o dos ocasiones posteriores se reavivaría el interés en el EXEC de TOPS-10, cuando se consideró la posibilidad de migrar los usuarios de TOPS-10 a TOPS-20, pero tales elucubraciones jamás duraron lo suficiente como para resultar en un producto.
Otra de las característica de compatibilidad desarrolladas durante el desarrollo temprano de TOPS-20 pero que no se incorporaron nunca al producto final fue la E/S de estructura de disco de TOPS-10. Esta permitía montar una estructura de disco TOPS-10 en el sistema TOPS-20, y permitir lectoescritura a los programas que corriesen en modo de compatibilidad TOPS-10. Logramos esto tomando una gran parte del código del sistema de archivos real de TOPS-10 y encapsulándolo con una interfaz de PA1050 por un lado y E/S directa a nivel de bloques por otro. De nuevo, esta resultó ser una función usada brevemente, si es que se usó alguna vez, por lo que nunca recibió esfuerzos adicionales. Al lanzar la siguiente versión del código del sistema de archivos TOPS-10, resultó más difícil de encapsular y ejecutar de esta manera, y se abandonó el uso de esta característica incluso para uso interno.
Es hora de tratar la historia de los nombres del sistema operativo que llegó a conocerse como TOPS-20. DEC había comprado los derechos comerciales de TENEX a BBN a principios de 1973 como parte del acuerdo de desarrollo de este nuevo sistema operativo. Sin embargo, como se esperaba un gran impulso de marketing para el nuevo sistema basado en el procesador KL10, se pensó necesario asumir un nuevo nombre para el sistema operativo. Por demás, el grupo de desarrollo de DEC pretendía ser independiente del grupo de BBN, que seguía desarrollando nuevas versiones de TENEX para los usuarios del KA10 de ARPA. Consideraron varios nombres durante los primeros meses. Finalmente, el gerente de ingeniería de KL10, Fred Wilhelm, declaró que el nuevo sistema operativo se llamaría VIROS. Parecía perfecto para la época: sugería "virtual", lo que iba a ser una característica clave del nuevo sistema, y tenía un sonido fuerte y viril. Desafortunadamente, John Leng (y otros) tendían a pronunciarlo como "virus", por lo que probablemente no habría sobrevivido, incluso si otros factores no lo hubieran hecho a un lado.
Posteriormente durante ese primer año, se decidió cambiar el nombre para confundir a la competencia. Esto formó parte de una política dictada desde "arriba" para evitar que el mercado supiese demasiado sobre desarrollos aún no anunciados. Sabíamos que prevenir tales filtraciones era imposible, por lo que la idea era confundir a todos con información contradictoria. El nuevo nombre elegido para el sistema operativo entonces fue SNARK, del cuento de Lewis Carol sobre La Caza del Snark, donde "lo perseguían con picas y antorchas". (Teníamos muchas) Ese nombre casi tuvo una vida corta, ya que se declaró además que los nombres de los códigos internos cambiarían cada seis meses para mantener al enemigo confundido. Cuando llegó el momento de cambiar el nombre tras los primeros seis meses, el grupo de desarrollo resistió la molestia de otra ofuscación más, pero finalmente cedió y presentó como nuevo nombre KRANS (SNARK escrito al revés). Desafortunadamente, pronto se descubrió que esta era una palabra que en sueco significaba "bóveda funeraria". Cambiaron rápidamente el nombre de nuevo a SNARK, y nuestra gerencia declaró entonces que no tendríamos que seguir con la locura del renombrado semestral.
Fue así que el nombre siguió siendo SNARK hasta el momento de anunciar el producto. Aún así no desaparecieron completamente estos diversos nombres provisionales; todos se usarían para otros fines internos, principalmente como nombres para volúmenes de disco en el grupo TOPS-20. De hecho, el paquete SNARK (pronunciado con acento de Boston) siguió siendo el hogar del código fuente de TOPS-20 durante toda la vida del sistema. SNARK y KRANS son actualmente nodos de la red interna de DEC pero no están en el grupo de ingeniería de 36 bits.
A medida que se acercaba el momento de anunciar del producto, se ponía una mucho mayor consideración al nombre del producto. Los meros ingenieros no formaban parte de este proceso, por lo que esperamos con anticipación que se transmitiera el nombre nuevo y final del sistema. ¿Se quedarían con SNARK (poco probable)? ¿Volvería a VIROS (los nombres con "V" eran cada vez más populares por entonces)? O crearían algo nuevo y dinámico?. El resultado fue, por decirlo suavemente, decepcionante. Aunque el nombre TOPS-20 se convirtió en un hecho de la vida, originalmente nos pareció el nombre menos emocionante e imaginativo que podrían haber elegido para un sistema nuevo y ordenado. Era igual que el sistema antiguo, TOPS-10, salvo por un dígito. Era casi tan creativo como ponerle "Wednesday Night at the Movies" a un nuevo programa de televisión de la misma época. Pero esa fue la historia: el nuevo producto sería el "DECSYSTEM-20" (alguien olvidó poner en minúsculas el "System" como en DECsystem-10) y el sistema operativo se llamaría TOPS-20.
Es por este motivo que - aunque el nombre TOPS-20 no se eligió hasta el momento inmediato antes de comercializar el primer sistema - he usado TOPS-20 para referirme al sistema operativo durante todo el tiempo que estuvo en desarrollo en DEC, es decir, desde enero de 1973 en adelante.
Durante su primer año el grupo TOPS-20 creció a cuatro personas. Además de mí, Peter Hurley y Arnold Miller mencionados anteriormente, se unió al grupo Len Bosack en los primeros meses. Tom Hastings también estuvo involucrado, sirviendo brevemente como supervisor. Aunque comenzó como parte de Ingeniería de Hardware de KL10, después del primer año este grupo nuevo hizo su transición a un lugar más lógico dentro de Ingeniería de Software.
Varios otros sirvieron como supervisores del grupo entre su formación y el primer envío comercial. En varias ocasiones, el grupo mismo contrataba a su nuevo supervisor. Para ahorrar tiempo, se establecía una entrevista con varios miembros del grupo a la vez que disparaban preguntas al desventurado candidato. Si el candidato no sobrevivía en interrogatorio, claramente no duraría en el funcionamiento diario del grupo. Los gerentes no fueron los únicos candidatos en recibir un escrutinio práctico. A Judy Hall - quinto miembro contratado en el grupo - y a otros que se unieron durante ese período, generalmente se les pedía que trajeran muestras de código fuente que hubiesen escrito previamente cuando acudían a las entrevistas.
El DECSYSTEM-20 (y TOPS-20) se comercializó por primera vez en enero de 1976, solo tres años después de que comenzara el desarrollo interno en DEC. Esto fue, por supuesto, más largo de lo que habíamos anticipado. Se habían ampliado los cronogramas tanto del hardware como del software, y se produjeron algunos otros cambios en los planes. Como se mencionó anteriormente, cuando comenzó el desarrollo del TOPS-20, el procesador KL10 ya se había apartado un poco de su concepción original de oficiar de reemplazo de "bajo costo" del procesador KI10. A medida que avanzaba el desarrollo de TOPS-20, proporcionamos un par de «mejoras» más a la máquina.
Una de ellos fue el direccionamiento extendido. TOPS-20 no forzaba involucrarse en este problema, pero pareció brindar la oportunidad de aprovecharlo eventualmente. Durante el período de 3 meses en el que trabajé en el desarrollo del KI-TENEX, Tom Hastings me sugirió por primera vez la posibilidad de ampliar el espacio de direcciones de memoria de la arquitectura PDP-10. En ese momento, parecía una idea bastante radical sugerir que 256 kWORDS de espacio de direccionamento podrían no ser suficientes para la mayoría de las aplicaciones, pero la PDP-11 ya estaba teniendo problemas en tal sentido y parecía prudente considerarlo para el PDP-10 mientras estábamos construyendo este nuevo procesador.
Había dos problemas principales que resolver al ampliar el espacio de direcciones del PDP-10. Primero, se necesitaría una forma de generar direcciones efectivas de más de 18 bits; en segundo lugar, se necesitaría un medio para mapear este espacio de direcciones virtuales más grande. A los diseñadores de hardware les pareció más formidable el segundo problema. Planificaron utilizar una RAM con tabla de búsqueda que realizase traducciones de direcciones de memoria virtuales a físicas, y contar con un espacio de direcciones más grande parecía requerir una RAM de traducción prohibitivamente grande. Para este propósito el KI10 había usado una memoria asociativa, pero los circuitos integrados disponibles en la tecnología del KL10 no proporcionaban una forma práctica de hacer una memoria asociativa.
Como resultado, la solución a este problema resultó recurrir un poco a la sinergia. Alan Kotok había estado buscando una forma de hacer que la memoria RAM de paginación fuese más pequeña incluso de lo que parecería ser necesario para el espacio de direcciones básico del PDP-10. Al utilizar 512 páginas en cada uno de los espacios de direcciones de modo usuario y ejecutivo, serían necesarias 1024 entradas para un esquema de mapeo directo. Alan estaba pensando en usar las mismas 512 entradas tanto para el usuario como para el ejecutivo, almacenando el bit de modo de usuario en la entrada y comparándolo en una búsqueda. Si la comparación fallaba, la entrada se consideraría inválida y se volvería a cargar desde memoria. Por lo tanto, la misma entrada podría utilziarse tanto para un usuario y una dirección de modo ejecutivo dados, y podría funcionar tan bien como una tabla de tamaño completo se tratara, siempre que no hubiese referencias demasiado frecuentes a las mismas direcciones de usuario y ejecutivo.
Mientras esto sucedía, me di cuenta de que no había nada único en el bit de modo de usuario en este esquema y que podía extenderse a un número de bits de dirección arbitrariamente grande. Es decir, un número determinado de bits para traducir podría dividirse en dos partes: una parte para indexar en la RAM y la otra parte para almacenar y comparar. Esto significaba que podíamos tener una cantidad de espacios para fines de direccionamiento extendido, cada uno tan grande como las 256 kWORDS originales, todos mapeados en la misma RAM de traducción. Cuanto más pequeña es la RAM, mayor es la posibilidad de conflicto, pero eso podría mitigarse un poco "creando" los bits de dirección para que los diferentes espacios de direcciones se compensen de manera diferente en la RAM.
En cuanto a las modificaciones al conjunto de instrucciones básicas, inicialmente decidimos ampliar el espacio de direcciones de 18 a 23 bits. Se eligió este número porque era el número de bits disponibles al combinar los campos Y, I y X de las instrucciones de PDP-10 (dirección, indirecto e índice). Tuvimos la suerte de que el conjunto de instrucciones del PDP-10 tenía un diseño muy limpio y consistente: cada instrucción calculaba su dirección de operando de la misma forma. Si este algoritmo pudiera modificarse para generar una dirección más grande, el problema se resolvería esencialmente para todas las instrucciones. La PC se podía hacer fácilmente tan grande como fuera necesario en hardware, y los diversos formatos de palabra en los que aparecía generalmente tenían los 5 bits adicionales disponibles.
A pesar de todo eso, cualquier modificación al conjunto de instrucciones tendiente a generar direcciones más grandes resultaría hasta cierto punto incompatible con el código preexistente. Para evitar la introducción de tales incompatibilidades, el diseño original tenía una forma especial de ejecutar una instrucción cuando se deseaba una dirección de operando extendida. La instrucción ejecutada normalmente generarba una dirección compatible de 18 bits, pero la misma instrucción ejecutada como operando de una instrucción de "ejecución especial" (SXCT) generaba una dirección más grande. Se hizo esto usando bits adicionales de una palabra indirecta o índice especificado en la instrucción.
Al final resultó que, nuestro diseño de direccionamiento extendido inicial había sido demasiado conservador. Incluso antes de que se enviara el primer DECSYSTEM-20, tuvimos la oportunidad de revisar y modificar en gran medida el diseño del direccionamiento extendido en relación con el proyecto UNICORN que se describirá más adelante.
Otra alteración del diseño del KL10 residió en el área de paginación. Debido al éxito logrado al correr una simulación del diseño de paginación de TENEX en el KI10, se asumió inicialmente que se podía hacer lo mismo sobre el KL10. Sin embargo, sabíamos que la simulación de software consumía una cierta cantidad de tiempo del procesador, ya que la aceleración de los programas TENEX que se portaban del KA10 al KI10 normalmente no era tanta como la calculada. Algunos estudios que utilizaron técnicas de muestreo de PC revelaron que el código de simulación de paginación a menudo requería más del 30% del procesador bajo una carga típica de tiempo compartido.
Esto trajo a colación una vez más el espinoso problema de incorporar los complejos algoritmos de paginación de TENEX en el hardware, algo que se había resistido tanto para el KA10 como para el KI10. Los ingenieros de hardware consideraban aún una mala idea dedicar tanto hardware a la paginación, pero afortunadamente existía otra posibilidad para el KL10: usar microcódigo. Así como la implementación KI-TENEX había demostrado que el algoritmo de recarga de página podía ejecutarse en software con el resultado entregado al hardware, también podría ejecutarse mediante microcódigo. El conjunto de instrucciones básico se implementaría en microcódigo en el KL10 (el primer procesador de arquitectura PDP-10 así diseñado), por lo que - según pensamos - podríamos agregar "solo un poco más de microcódigo" creando un algoritmo de paginación.
Se hicieron necesarios algunos cambios en el diseño de hardware del KL10 tal como existía en ese momento para permitir que el microcódigo obtuviese el control cuando fallaba un intento de traducción de dirección, calculando la traducción y cargándola en el búfer de traducción, para luego continuar con la instrucción cuya ejecución se hallaba en curso. Eso se solucionó con poco hardware adicional, y pareció que finalmente habíamos logrado dar soporte completo de la arquitectura de paginación. Con un poco de miopía típica de esa época, consideramos resueltos todoss nuestros problemas de rendimiento de paginación, ya que todo lo que se hacía en microcódigo tenía que ser increíblemente rápido. ("Microlocura", como solía llamarla Len Bosack).
Por lo tanto, el KL10 contó con las capacidades extendidas de direccionamiento y paginación de TOPS-20 cuando se comercializó por primera vez. Es posible que esas mejoras extendieran un poco el cronograma de desarrollo, aunque argumentamos en el momento en que se consideró cada una de ellas que el trabajo adicional era insignificante considerando el panorama general. No estoy muy seguro de cómo finalmente conseguimos que se aprobaran estas cosas. Recuerdo que Win Hindle - bastante enojado - prácticamente nos echó de su oficina la primera vez que entramos para hablarle sobre agregarle direccionamiento extendido a la máquina.
Mientras estábamos molestando al grupo de hardware con cambios en la paginación y el direccionamiento extendido, también estábamos ocupados en una gran cantidad de proyectos de software. Un proyecto típico para robustecer el sistema para su uso comerciales fue el de modificar el manejo del sistema de escritura y tablas de asignación de disco. Esencialmente tanto en TENEX como TOPS-20, todas las E/S de disco se iniciaban mediante paginación. Las páginas de archivos se asignaban - ya sea en el espacio de direcciones del usuario o del ejecutivo - y se leían o escribía como instrucciones ordinarias. En lo que respecta a DEC, en TENEX todas las páginas de archivos se trataban por igual - incluidas las de directorios, tablas de páginas y tablas de asignación de discos. Esto funcionaba bien siempre que el sistema no fallara. Si el sistema se desactivaba intencionalmente, su último acto era escribir todas las páginas modificadas en el disco y, por lo tanto, hacer que el disco fuese coherente.
Sin embargo, si el sistema colapsaba (lo cual ocurría ocasionalmente), podría fácilmente suceder que se hubiera escrito en el disco un conjunto de páginas inconsistente. Un directorio de archivos podía apuntar a un archivo para el que no se había escrito tabla de páginas, o bien podía encontrarse en uso páginas para las que no se hubiesen actualizado su tabla de asignación. Para encargarse de esto, la práctica en TENEX era correr un programa de verificación de consistencia de disco llamado CHECKDSK. En particular, este marcaba la tabla de asignación para cualquier página que se enconstrase en uso para evitar asignaciones múltiple. Esto había sido satisfactorio al principio, pero con el aumento en la cantidad de archivos en almacenamiento, había comenzado a llevar mucho tiempo. La solución fue forzar la escritura de las tablas de asignación, las tablas de páginas y los directorios en ciertos puntos y en cierto orden usando técnicas ahora bien conocidas. Es interesante notar que Unix afrontó problemas similares en sus primeras versiones, y en versiones más recientes tuvieron que aplicar las mismas técnicas .
Otro paso interesante fue el desarrollo de COMND JSYS. Esta llamada de sistema proporcionaba un conjunto de servicios para implementar el estilo de interfaz de comando TOPS-20 (reconocimiento de escape, ayuda con el signo de interrogación, etc., como se explicó anteriormente). Sin embargo, no formaba parte de TENEX ya que procedía de BBN. Más bien, esas características de la interfaz se programaron individualmente en cada aplicación que las admitía y - de hecho - solo EXEC las admitía en general. Otros programas generalmente solo admitían el reconocimiento de nombres de archivos, ya que este era proporcionado por la llamada al sistema GTJFN. Incluso la edición básica de la línea de comandos (rubout para eliminar un carácter, control-U para borrar la línea, etc.) no se hallaba centralizada y varios programas la proporcionaban más o menos o no la proporcionaban en absoluto.
Abordamos la necesidad de una edición de línea de comandos centralizada anteriormente en el desarrollo de TOPS-20 mediante la adición de TEXTI JSYS (y los subconjuntos relacionados RDTXT y RDLINE). Se había hecho particularmente notorio las disposiciones ad hoc de los diversos programas de utilidad con el uso cada vez mayor de terminales de video. Con TEXTI, nos comprometimos tanto a centralizar las funciones de edición de líneas como a hacerlas sensibles al tipo de terminal utilizada. En ese momento, todavía era impresionante aprovechar la capacidad de la terminal de video para borrar un carácter o una línea. Algunos sistemas de terminal de video habían podido agregar al menos un soporte mínimo de edición de línea porque solo admitían entrada en línea y el almacenamiento en el búfer de línea se realizaba de manera centralizada. Sin embargo, TENEX había sido diseñado considerando un máximo de flexibilidad para la terminal y, por lo tanto, no tenía una forma unificada de editar la entrada. TEXTI JSYS proporcionó muchas opciones para que también pudiese utilizarse por programas que querían más o menos entradas de línea a la vez.
Sin embargo, la implementación de una biblioteca de entrada de comandos centralizada no fue un elemento que apareció en nuestra planificación. El último año antes de que se comercializara el sistema habíamos identificado y estábamos trabajando en algunos programas de utilidades que requerían mejoras específicas. Uno de ellos era DUMPER (utilidad de copia de seguridad y restauración de disco a cinta), que tenía una interfaz de comandos particularmente mala. Tuve la tarea de mejorar la interfaz de usuario de DUMPER para alcanzar un nivel mínimo de aceptabilidad, pero lo había estado postergando porque sería algo rutinario y aburrido. Mientras tanto, comencé a pensar en cómo podría centralizarse este estilo de interfaz de comando en un conjunto de funciones y tablas.
Debido a la naturaleza altamente interactiva de la interfaz, se hacía necesaria la ejecución parcial del programa durante la entrada del comando. Por ejemplo, al intentar reconocer el nombre del archivo, debían estar disponibles los valores predeterminados y cualquier otro contexto pertinente para poder determinar éxito o fracaso. Sin embargo, el programa no debía realizar acción irrevocable alguna hasta dar confirmación el comando (normalmente con la tecla retorno de carro) para que el usuario fuese capaz de borrar todo o parte del comando con las teclas de edición de línea. Incluso el TENEX Exec original no entendía esto del todo bien. Era posible para el usuario borrar toda la línea de comando con control-U, pero no podía borrar hacia atrás más allá del campo actual. En otras palabras, el EXEC sabía cómo vaciar todo el estado de la línea actual y comenzar de nuevo, y sabía cómo eliminar caracteres del campo actual antes de autocompletarlo, pero no sabía cómo vaciar parte del estado y copia de seguridad en un campo ya completado.
Mi idea para resolver este problema de la copia de seguridad no era hacer una copia de seguridad en absoluto, sino almcacenar el texto del comando y luego volver a escanearlo desde el principio con la parte no deseada removida. En vez de mejorar unicamente el DUMPER, con esta idea en mente y una lista de funciones para manejar los diversos tipos de campos que se producirían en una línea de comando, me dí a escribir una instalación de tipo biblioteca. Por supuesto, DUMPER estaba destinado a ser - y se convirtió - en el primer programa en usar esta nueva función, pero al momento del primer lanzamiento de TOPS-20, estas rutinas de análisis de comandos se habían integrado al monitor bajo el nombre de COMND JSYS. Aún así, la mayoría de las utilidades estaban modificadas para usarlo y el EXEC aún carecía de código de análisis original. La corrección a todo esto se fue sumando en versiones posteriores.
En última instancia, la mayor parte del desarrollo de TOPS-20 realizado para la primera versión se destinó a admitir nuevas arquitecturas y dispositivos de hardware. Era necesaria una estructura completamente nueva de E/S para almacenamiento de masa en discos y cintas Massbus, y se hacía necesario un cambio igualmente grande para manejar las comunicaciones de E/S a través del front-end PDP-11 en lugar de a través de hacerlo con escáneres de línea directa.
Desde la primera rutina de arranque del PDP-6, casi todo el código fuente del sistema para las máquinas con arquitectura de 36 bits había sido escrito en MACRO. Debido a su estructura regular y su potente conjunto de operaciones, el lenguaje ensamblador de 36 bits era razonablemente agradable de escribir y, por lo tanto, existía menos presión para un lenguaje de nivel superior que en la mayoría de las otras máquinas. BLISS haba ganado adeptos en algunas partes de DEC, pero sus peculiaridades diversas (por ejemplo, la notación de "punto" y el uso de guiones bajos para el operador de asignación en la versión anterior de -10) generaron una gran rechazo en otras instituciones. Por tal motivo, el código fuente nuevo de TOPS-20 terminó escribiéndose en MACRO, tal como lo había sido TENEX.
Durante el desarrollo de la versión 1 y a posteriori, a las convenciones de programación MACRO utilizadas en TOPS-20 fueron agregándose funciones nuevas. Estas fueron implementadas principalmente por macros, y le otorgaron ciertas capacidades de lenguaje de nivel superior a MACRO. El primero de estos mecanismos involucraba representar estructuras de datos in situ (es decir, en un archivo de "encabezado") de modo que la representación provocase la generación de un código fuente apropiado para referenciamiento. Esto comenzó en forma de una macro simple que seleccionase la "mitad izquierda" o la "mitad derecha" de un WORD de 36 bits (en lugar de un HLxx o HRxx explícito). Luego vinieron las macros capaces de seleccionar la instrucción de prueba de bits correcta (TLxx, TRxx, TDxx) de la máscara en cuestión. Finalmente, las macros resultaron capaces de definirse y representar así estructuras complejas de tipo registro multiWORD con campos de variados tamaños.
En segundo lugar, se usaron macros para proporcionar llamadas a procedimientos y almacenamiento automático (pila) usando variables con nombre. Podría declararse el punto de entrada de un procedimiento usando nombres simbólicos para los parámetros, y estos nombres podían expandirse a la referencia de pila apropiada se se los empleaba en una instrucción. De manera similar, era posible definir el almacenamiento de pila local de forma simbólica, y los registros locales se almacenarían así automáticamente. Estas convenciones redujeron en gran medida la aparición de instrucciones de pila explícitas PUSH y POP, y como consecuencia disminuyeron los errores que a menudo resultaban de ellas.
Finalmente, se implementaron macros para proporcionar estructuras de control sin hacer uso explícito de etiquetas. Semánticamente, se parecían a las construcciones IF/THEN o IF/THEN/ELSE del lenguaje típico, pero permitían el anidamiento arbitrario. Como resultado, una página típica de código TOPS-20 que usaba estas convenciones a menudo contenía una única etiqueta: la del punto de entrada del procedimiento.
Todas estas técnicas mejoraron la programación, pero, por supuesto, no eliminaron la dependencia del conjunto de instrucciones del PDP-10. La portabilidad no fue un objetivo que nos preocupara hasta que fue demasiado tarde.
Las consecuencias del ambicioso conjunto de nuevas arquitecturas las comenzaron a sentir tanto los ingenieros de hardware como nosotros los del software. A medida que los cronogramas avanzaban, no pasó mucho tiempo antes de que a alguien se le ocurriera la idea de comercializar al KL10 como una mera actualización del procesador para los sistemas DEC-10 existentes. Después de todo, la introducción de nuevos procesadores estaba bien establecida y parecía una fuente de ingresos significativa mucho antes de que el DECSYSTEM-20 completo estuviera listo. Fruto de ello nació el proyecto y producto "1080".
El 1080 consistía el procesador KL10 con adaptadores para conectar a las memorias externas KI10 y al bus E/S. Ni la memoria externa ni el bus de E/S estaban destinados a ser parte de la nueva arquitectura, pero se agenciaron los adaptadores con el interés de generar algunos ingresos para capear el costoso desarrollo del KL10. Como el 1080 se vendería a los clientes existentes bajo la forma de actualizaciones para sus sistemas, se entregaría solo con el sistema operativo existente, TOPS-10. No fue mucho trabajo que TOPS-10 corriese en el KL10; la máquina incluso tenía un modo que emulaba la paginación KI10 en lugar de la nueva paginación basada en microcódigo diseñada para TOPS-20. Fue este motivo el cual - después de toda la emoción original en torno al maridaje de TOPS-20 con el procesador KL10 - resultó TOPS-10 el incluido junto a los primeros KL10 en salir a la venta.
El primer envío de 1080 en agosto de 1975 fue ocasión de una gran celebración frente a la planta de Marlboro. Toda la línea productiva de 36 bits había sido trasladada a la planta de Marlboro a principios de 1974, lo que significaba que teníamos los grupos de fabricación, ingeniería, marketing y todos los demás en un solo lugar. Más tarde, esta naturaleza autónoma de la línea de 36 bits - junto con el hecho de que continuamos construyendo una arquitectura diferenciada de la corriente principal de la empresa - llevó a algunos a referirse a la línea de productos 10/20 como "La empresa de informática Marlboro".
Con ocasión del primer envío de la 1080, la mayoría de los grupos de Marlboro se reunieron para pronunciar discursos frente a un gran camión de Digital destinado al primer cliente de 1080. En realidad, el camión estaba vacío en ese momento debido a algunos inconvenientes de última hora, pero el producto estaba sustancialmente listo y comenzó la fiesta.
Mientras esto transcurría, continuó el desarrollo en el DEC-20. Al utilizar estas nuevas arquitecturas y gracias a las velocidad de CPU, el nuevo sistema resultaría mucho más rentable que los anteriores. Por tal motivo, la línea de productos retrasó su anuncio hasta poco antes de que estuviera listo para enviarse. Todo esto tuvo lugar en enero de 1976. La primera media docena de clientes del DEC-20 fueron cuidadosamente seleccionados para efectuar lo que sería realmente una prueba de campo del nuevo sistema.
Durante los primeros dos o tres años después de que el DEC-20 comenzó a comercializarse, disfrutó de cierto favor dentro DEC. Sin embargo, incluso al momento del primer envío, había señales claras de que la línea principal de productos DEC pasaba por otra serie: a la familia PDP-11 le estaba yendo muy bien y hacía mucho dinero para la Corporación, y ya estaba en marcha un diseño de máquina que luego sería conocida como VAX. Sin embargo, hubo un tiempo en que pendió de un hilo, en retrospectiva, esta parte significativa de la historia.
Para 1975 estaba claro que la arquitectura PDP-11 había alcanzado su cénit. En particular, su espacio de direcciones era demasiado limitado para admitir muchas aplicaciones en desarrollo. Se inició un esfuerzo para construir una nueva máquina que se vendería en el extremo superior del rango de precios de las PDP-11 y más allá, y constituiría el camino de crecimiento para los usuarios de PDP-11. Esta nueva máquina, que recibió el nombre código de UNICORN, se basaría en la arquitectura de 36 bits dado que ya existía un compendio de software disponible para esta. Comenzaron a venir a Marlboro varios de los ingenieros de más alto rango en los grupos PDP-11 para hablar sobre la construcción de un PDP-10 pequeño (pequeño para nuestra forma de pensar), pero grande en comparación con la línea PDP-11.
Como resultado de este trabajo se revisó el diseño original para incorporar direccionamiento extendido de memoria. Los ingenieros de PDP-11 insistieron en mejorar el diseño de direcciones extendidas para mejorar la eficacia final, con miras más elevadas apuntando al rendimiento para el comercio, y una mayor apreciación del dolor de quedarse sin espacio para direcciones. Nos convencieron que el rendimiento no debía verse comprometido por razones de compatibilidad o conversión como habíamos contemplado en el diseño original.
Surgió así un nuevo diseño de direccionamiento extendido que a largo plazo constituyó una gran mejora. Sin embargo, ya era demasiado tarde para implementarlo por completo en el procesador KL10 inicial. El nuevo diseño incorporaría un direccionamiento de 30 bits en lugar de 23. También eliminaría la "ejecución especial" porque eso habría agregado un ciclo de cómputo adicional a cada referencia extendida y habría afectado el rendimiento general de los programas que utilizan en gran medida el direccionamiento extendido. En su lugar se proporcionó compatibilidad en función del uso del espacio de direcciones. El espacio de direcciones general fue dividido en "secciones" de 256 kWORDS cada una. En la sección 0, denominada "sección conmemorativa KI", el código funcionaba exactamente como lo había hecho en el procesador KI10, es decir, sin posibilidad de direccionamiento extendido alguno. Sin embargo, si el PC se encontraba en una sección distinta de 0, utilizaría un algoritmo diferente para calcular la dirección, de modo de poder generar una dirección extendida (intersección) en cualquier momento. Estas diferencias tendrían como consecuencia que el código carecería de compatibilidad estricta, pero el estilo y la sensación general de programación serían muy parecidos. No se necesitaba alterar la gran mayoría de las instrucciones del código para que corriesen en el entorno extendido y bastaba con meras modificaciones parciales, por lo que sentimos que habíamos logrado proporcionar un camino franqueado para migrar código preexistente.
Irónicamente, como es previsible, el proyecto UNICORN nunca llegó a buen puerto. Se llegó a la conclusión en un tiempo relativamente breve que - incluso pudiendo construir una ordenador barato de arquitectura de 36 bits - no sería "culturalmente compatible" con el software y aplicaciones de la PDP-11 y por lo tanto no satisfaría la demanda. En su lugar, decidió formar un grupo central de diseño que proveyera una arquitectura culturalmente compatible con la PDP-11 pero que diera cuenta de las limitaciones del espacio de direccionamiento que tenían aquellas. Eventualmente, la máquina construida como resultado de tal esfuerzo fue designada VAX-11, por "extensión de direccionamiento virtual" del PDP-11. Sin embargo - como se sabe - los diseñadores hicieron mucho más que simplemente extender el espacio de direcciones. Lo que no está difundido es que - al menos durante un tiempo - ¡se planeó que la VAX tuviese 36 bits!
El direccionamiento extendido no fue la única forma en que la VAX impactó sobre la primera versión del DECSYSTEM-20. Cuando se comenzó a comercializar el DECSYSTEM-20, ya estaba en marcha el diseño de software y hardware para la VAX. En un esfuerzo por reducir el abanico de interfaces de comando diferentes entre los productos DEC, se formó un comité para que especificara un lenguaje de comando estándar de DEC, o DCL. En tal momento, los lenguajes existentes para el intérprete de comandos de sistema incluían TOPS-10, TOPS-20 y varios sistemas PDP-11: RSX, RSTS, RT-11, IAS y otros. Se tuvo la intención - como parte de la emergente estrategia de "un sistema" - que este nuevo estándar de lenguaje de comandos afectase los sistemas existentes siempre que fuera posible y, especialmente, que guiara la implementación de todo el software nuevo para la VAX.
Hubo varias áreas controvertidas en las que el ejemplo implementado en TOPS-20 resultó finalmente persuasivo y se tomó como base para el estándar DCL. Por ejemplo, se adoptó el orden de TOPS-20 de COPY (COPY origen destino) en lugar del estilo de asignación (COPY destino=origen) habitual en TOPS-10 y otros. Hubo sin embargo un área en la cual TOPS-20 acordó una modificación como respuesta al consenso del comité. Hasta este momento, TOPS-20 había continuado con la práctica de TENEX de usar punto y coma como puntuación para indicar el número de generación de un fichero, por ej. NOMBRE.EXT;3 para la tercera generación del fichero NOMBRE.EXT. Ya bastante tardíamente en el proceso, caímos en cuenta que la convención de generación no requería necesariamente un carácter de puntuación distinto al de la extensión y que sería más económico usar el mismo punto, por ejemplo NOMBRE.EXT.3. Estuvimos de acuerdo en eso, aunque significaba alterar algo del código en proximidad de la fecha del lanzamiento de TOPS-20. No obstante, lo hicimos para no enfrentar el problema de incompatibilizar el cambio en una versión posterior.
Desafortunadamente, los desarrolladores del sistema operativo VMS ya habían comenzado a usar el punto y coma y se resistieron a hacer el cambio. En última instancia, esta alteración jamás se llevaría a cabo y el software VMS terminó utilizando punto y coma. El estándar resultó siendo modificado para volver a integrar el punto y coma, pero ya habíamos comercializado al TOPS-20 utilizando punto. A raíz de este malentendio perdimos una pequeña oportunidad de compatibilizar DECSYSTEM-20 con VAX a pesar de nuestros mejores esfuerzos políticos para lograrlo.
Si bien el fin formal de la familia de productos de 36 bits no se anunció sino hasta 1983, la vida en la Tierra de los 36 bits ya parecía precaria muchos años antes de alcanzar dicha fecha en el calendario. El KS10 se construyó con el fin de agregar un producto de gama baja a la familia, y se lo comercializó como como "2020" aproximadamente un año después de la introducción de la línea DECSYSTEM-20. Sería este la última instancia de procesador en presentarse. A pesar de esto, se iniciaron varios otros.
Uno fue el conocido como proyecto Dolphin, que constituiría una máquina de gama alta con un rendimiento mucho mayor que el KL10. Sin embargo, se llevó a cabo como desarrollo combinado de 36 bits/VAX. Es decir, la mayor parte de la ingeniería estuvo destinada a aplicarse por igual tanto a un procesador VAX como uno de 36 bits, y se supuso necesitaría sólo un poco de trabajo específico sobre la arquitectura para lograr cada versión. Esto, sumado a otras complejidades tecnológicas y los elevados objetivos de rendimiento, significaron que el proyecto fuese más allá de las capacidades disponibles en ese momento. Los costos se dispararon y el proyecto se atascó. A principios de 1979, el secotr de 36 bits del proyecto fue cancelado y solo el sector VAX - por entonces denominado VENUS - continuó en pie y finalmente resultó en el VAX 8600.
Otro proyecto cancelado más o menos al mismo tiempo fue una PDP-10 muy pequeña conocida como Minnow. Este proyecto - que operaba en una pequeña trastienda del segundo piso de la planta de Marlboro - había dado como resultado la construcción de una plaqueta de evaluación que funcionaba lo suficientemente bien como para demostrar algunos programas de modo ejecutivo. Consistía en tres placas grandes: una placa de procesador que incluía 8 UARTS para líneas de comunicación, una plaqueta de memoria y una plaqueta controladora de disco. Estas podrían colocarse sobremesa, pero se concibieron para residir en un gabinete tipo escritorio con un disco fijo y otro extraíble. Si esta máquina no hubiese sido cancelada, creo que habría representado una entrada significativa en lo que luego se convirtiría en el mercado de las estaciones de trabajo. No era una estación de trabajo completa - ya que no habíamos anticipado el valor de contar con un sistema de visualización integrado - pero habría sido una computadora "personal" y un producto con costo/rendimiento varios años por delante del mercado.
Sucumbió en parte a la determinación corporativa de adherirse a la estrategia de arquitectura única de VAX. Si bien el producto Minnow parecía atractivo, se consideró que enviaría un mensaje equivocado al introducir una máquina que distinta a la VAX en su rango de precios. Además, Minnow también contaba con un apoyo limitado dentro de los grupos DECSystem-10 y DECSYSTEM-20. Muchos allí consideraban que las máquinas de 36 bits vivían únicamente en salas de cómputo para ser rodeadas de grandes discos y unidades de cinta, y no podían entender cómo una máquina pequeña de oficina podría ser útil. Esto parecía ser parte de un conservadurismo mayor que impidió o desanimó intentos significativos en el campo de quienes pensaban sostener o expandir el negocio de 36 bits.
Para 1979, la línea de 36 bits había sido cancelada - esencialmente - nuevamente [ver sección 1.2]. Sin embargo, la Corporación de Equipamientos Digitales no estaba lista del todo para declarar esto al mundo. A las VAX les estaba yendo bien, pero no estaban listas para hacerse cargo de todo el negocio de alta gama. A raíz de la cancelación del proyecto Dolphin, se decidió construir una última máquina con arquitectura PDP-10, que se llamaría "2080". Este proyecto estaría separado de cualquier desarrollo de VAX. Sería una máquina simple, de bajo costo, predecible y limitada a producir un sucesor rentable del procesador KL10. Estos objetivos limitados provocaron una mentalidad de quiebre entre los grupos de 36 bits. Se archivaron los planes ambiciosos a largo plazo y se reenfocaron los proyectos en estrategias resultadistas de corto plazo. El único propósito oficial para construir el 2080 fue el de "apoyar a los clientes actuales", es decir, no intentar hacer crecer el negocio y "jugar al empate".
Un área afectada por esto fue TOPS-10 y las perspectivas de una estrategia de un solo sistema. Mientras continuaba el desarrollo de Dolphin, se invirtió algo de esfuerzo en considerar lo que se necesitaría para hacer que TOPS-20 fuera totalmente capaz de englobar a todos los clientes de 36 bits. Se habían llevado a cabo estudios de rendimiento para delimitar las áreas en las que el rendimiento de TOPS-20 fuese inferior al de TOPS-10. Se consideraron problemas de redes y multiprocesamiento. Sin embargo, con la cancelación de Dolphin y la estrategia de cierre del negocio, claramente no tenía sentido trabajar en mudar a los clientes de TOPS-10 a TOPS-20, por lo que estos objetivos fueron descartados una vez más, y se desenfocó la estrategia. Cada grupo de sistemas continuó con el desarrollo que le parecía pertinente, en muchos casos realizando proyectos en esencialmente duplicados para dar soporte a su hardware.
Otra víctima probable de las metas limitadas en el ámbito de de 36 bits fue TOPS-20 SMP. La arquitectura de TOPS-20 se adaptaba bien a SMP porque se consideró las necesidades de ese estilo de operación al diseñar TENEX. El sistema no solo habría soportado fácilmente el tiempo compartido de SMP, sino que su estructura de procesos también habría permitido que los programas de usuario diesen inicio fácilmente a tareas paralelas dentro de un solo trabajo.
El producto TOPS-20 inicialmente no era SMP porque el hardware DECSYSTEM-20 inherentemente contaba con una sola CPU. Utilizando memorias externas - como las utilizadas en las configuraciones TOPS-10 - se podría haber admitido SMP. De hecho, TOPS-10 SMP fue uno de los aspectos más exitosos del estudio amplio de TOPS-10. Sin embargo - por decisión productiva - el DECSYSTEM-20 NO se configuraría con memoria externa y - por lo tanto - no podría correr en una configuración de hardware compatible con SMP. El 2020 también contó con una única CPU. Se planeó que Dolphin fuese una máquina multiprocesador, y se incluyó SMP en los planes de desarrollo iniciales de TOPS-20 del momento, pero al cancelar Dolphin se eliminó dicha posibilidad para tal plataforma de hardware.
Curiosamente, TENEX sí resultaría modificado para admitir SMP, pero no en DEC o BBN. En el Centro Médico de la Universidad de Stanford se ensambló una configuración KI10 de dos procesadores, y Rainer Schultz de Stanford modificó el KI-TENEX para que funcionase como un sistema operativo SMP completo. Este sistema estuvo operativo alrededor de 1977 e incluso se llevaron a cabo algunas conversaciones con DEC respecto a agregar las modificaciones SMP a TOPS-20. Aún así nunca se obtuvo nada de esto, ya que el producto de hardware DECSYSTEM-20 definido nunca incluiría una posible configuración SMP.
A medida que el proyecto 2080 continuaba, se extendió la larga tradición de 36 bits de recoger algunos "agregados" aquí y allá. En poco tiempo se desarrollaron algunas proyecciones de rendimiento muy ambiciosas debido en gran parte al uso planificado de técnicas de canalización. El conjunto de instrucciones PDP-10, por su relativa simpleza (aunque no tan simple como un conjunto de instrucciones RISC), parecía prestarse a una gran cantidad de canalización, particularmente si los compiladores podían generar secuencias de código optimizadas. Empezó a parecer que la experiencia KL10 podría repetirse y otorgar a la arquitectura de 36 bits una nueva oportunidad de vida.
Otro cambio al plan original fue la inclusión de la estrategia de interconexión DEC aparecida por entonces. Esta requería que los dispositivos de almacenamiento masivo se conectaran a través de controladores CI y HSC, y que otros periféricos pudiesen conectarse a través de Ethernet. Aproximadamente dos años después de iniciado el proyecto, este sistema fue redefinido para utilizar exclusivamente estas nuevas interconexiones, descartando el soporte Massbus, Unibus y otras interconexiones previas. El proyecto pasó a llamarse JUPITER, renació así la línea de productos LCG y en gran medida desaparecieron del grupo los pensamientos de cerrar el negocio.
Como consecuencia de ello se llevaron a cabo importantes esfuerzos de desarolllo de software. Más allá del soporte básico de hardware, se nos ocurrió el concepto de Common File System como un medio para dar soporte a sistemas con múltiples CPU. Se estaba realizando un trabajo acorde en el grupo VAX/VMS que llegó a ser conocido como Clusters. En última instancia, tanto VMS como TOPS-20 contaron con este tipo de capacidad. Las implementaciones sería diferentes y reflejaron las diferencias en los dos sistemas. VMS usaba un administrador de bloqueo de clúster como método básico para regular el acceso simultáneo a los ficheros, mientras que TOPS-20 incrustó el bloqueo en las rutinas primitivas básicas de apertura de ficheros. La implementación de TOPS-20 también continuó utilizando el mapeo de memoria virtual como paradigma para hacer referencia a los archivos, y es posiblemente el único sistema que implementó el acceso distribuido a la memoria virtual compartida.
Una vez más, se generaron algunas ideas en torno a la posibilidad de pasar a una estrategia de sistema operativo único para máquinas de 36 bits. Durante un breve período, se imaginó un sistema que combinase de alguna manera todas las bondades de TOPS-10 y TOPS-20. Este se llamaría TOPS-36 para no hacer pensar a los partidarios de TOPS-10 o TOPS-20 que era solo el otro. Es imposible decir qué podría haber resultado de esto, ya que nunca se hizo planificación o diseño alguna más allá de definir escenarios generales.
La mayoría de estos ambiciosos planes se redujeron o abandonaron porque JUPITER no repitió la historia de KL10; más bien fue más como la historia de los delfines. Nunca se puede saber con certeza si el proyecto "agregó demasiadas características" o si se cometieron otros errores evitables. Sin embargo, después de haber recibido una gran extensión de tiempo y una infusión adicional de fondos de desarrollo, el proyecto dio cuenta que iba a necesitar mucho más de ambos. Además, ciertos análisis retrasados durante mucho tiempo sobre rendimiento de ciertas instrucciones comunes de 36 bits llevaron a la conclusión de que el rendimiento general no estaría a la altura de las expectativas. De hecho, en algunos casos difícilmente superaría al KL10. Probablemente habría sido posible solucionar esos problemas, pero el proyecto ya estaba muy sobrepasado y parecía atascado en replanteos semanales e indecisión.
La temprana popularidad de TENEX en ARPANET fue sin duda una clave para su posterior aceptación, transformación y soporte bajo el nombre TOPS-20 por parte de DEC. Dicha popularidad - a su vez - parece haberse basado no solo en sus características técnicas, sino también en el hecho de que se desarrolló dentro de esa comunidad y respondió a ella. Cuando TOPS-20 se convirtió en un producto DEC, se convirtió en parte de un mercado mucho más grande y, por lo tanto, menos receptivo a cualquier segmento particular del mercado.
Además de eso, a medida que aumentó el interés en otras arquitecturas de cómputo a finales de los años setenta, muchos instituciones de investigación llegaron a la conclusión de que no querían depender de ningún proveedor de hardware o software y, en cambio, querían sistemas "abiertos" que fuesen susceptible de modificación y evolución local. Esto - por supuesto - condujo a un rápido aumento en el uso y la popularidad de Unix. El hecho de que Unix se implementara en un lenguaje razonablemente portátil (al menos en comparación con MACRO de 36 bits) también alentó su difusión a nuevas arquitecturas de chips y más allá. Si hubiera podido hacer algo diferente en la historia de TENEX y TOPS-20, habría sido programarlo en un lenguaje de nivel superior. Con ello, es probable que el sistema, o al menos una gran parte de él, se hubiese extendido a otras arquitecturas y finalmente habría sobrevivido a la desaparición de la arquitectura de 36 bits.
Gran parte del éxito de TOPS-20 y otro software de 36 bits fue resultado de las cualidades que surgieron de los entornos interactivos en los que se creó y utilizó. En los últimos 10 años, la fuerza motriz de los entornos interactivos ha sido acercar el poder de la computadora al usuario a través de computadoras personales y estaciones de trabajo. Para que TOPS-20 se mantuviera a la vanguardia del desarrollo y uso interactivo, se tendrían que haber construido plataformas de hardware de 36 bits que fueran lo suficientemente pequeñas y baratas para ir a la oficina, o el software tendría que haber sido lo suficientemente portable para pasar a otras plataformas similares.
Aunque este libro trata sobre la arquitectura de 36 bits de DEC, ahora está claro que las arquitecturas de CPU de hardware están perdiendo importancia en la configuración del software. Durante mucho tiempo, las arquitecturas de conjuntos de instrucciones impulsaron la creación de nuevo software. Se introduciría una nueva arquitectura y se escribirían nuevos sistemas de software para ella. La arquitectura de 36 bits era grande en comparación con la mayoría de los otros sistemas que permitían el uso interactivo. También tenía un costo inferior que la mayoría de los otros sistemas de ese tamaño. Estos factores fueron importantes en la creación del tipo de software por el que la arquitectura es conocida.
Ahora bien, están apareciendo con una frecuencia cada vez mayor nuevas arquitecturas, pero simplemente "se deslizan" debajo del software. Los sistemas de software son demasiado grandes para reescribirlos cada vez que sale nuevo hardware, y un sistema incapaz de adaptarse a las nuevas arquitecturas eventualmente sufrirá una disminución del interés y la pérdida de plataformas de hardware competitivas. TOPS-20 no superó dicha prueba, aunque aportó una serie de ideas a la tecnología de los sistemas interactivos. Hasta dónde se han difundido finalmente dichas ideas es una historia que aún no se ha contado.
1. "TENEX, un Sistema de Tiempo Compartido Paginado para el PDP-10". Daniel G. Bobrow, et al. CACM, Vol 15 No 3, marzo de 1972.
2. "Estructura de un sistema LISP que utiliza almacenamiento de dos niveles". Daniel G. Bobrow y Daniel L. Murphy. CACM, Vol 15 No 3, marzo de 1967.
3. "Una nota sobre la eficiencia de un cálculo LISP en una máquina paginada". Daniel G. Bobrow y Daniel L. Murphy. CACM, Vol 11 No 8, agosto de 1968.
4. "El modelo de conjunto de trabajo para el comportamiento del programa". Peter J. Denning. CACM, Vol 11 No 5, mayo de 1968.
5. "Organización y Gestión del Almacenamiento en TENEX". Daniel L. Murphy. Actas AFIPS, 1972 FJCC.
6. "Implementación de TENEX en el KI10". Daniel L. Murphy. Sesión del Panel TENEX, NCC 1974.