Grandes sistemas de Burroughs

El B5000 fue revolucionario en su tiempo al ser la arquitectura y el conjunto de instrucciones diseñados tomando en consideración las necesidades del software. Esto era un alejamiento del diseño del sistema de computación de ese tiempo, donde un procesador y su conjunto de instrucciones serían diseñados y después entregados a la gente del software, y todavía es así. Es decir, las arquitecturas modernas como el x86 o el PPC son esencialmente arquitecturas basadas en conjuntos de instrucciones tradicionales en vez de diseños holísticos como los sistemas originales de Burroughs.

El B5000 fue diseñado para soportar exclusivamente lenguajes de alto nivel. Esto ocurrió en un tiempo en que tales lenguajes comenzaban a ser prominentes con FORTRAN y luego COBOL. FORTRAN y COBOL eran considerados lenguajes débiles por algunos, comparado con técnicas modernas de software, así que fue adoptado un lenguaje nuevo que no había sido probado, ALGOL-60. El dialecto del ALGOL seleccionado para el B5000 fue el Elliott ALGOL, primero diseñado e implementado por C.A.R. Hoare en un Elliot 503. Éste era una extensión práctica del ALGOL con instrucciones de I/O (que el ALGOL había ignorado) y poderosas instrucciones de procesamiento de cadenas. La famosa conferencia de Turing de Hoare fue sobre este tema.

Así el B5000 fue basado en un lenguaje muy poderoso. La mayoría de los otros proveedores solamente podían soñar en implementar un compilador ALGOL y la mayor parte de la industria descartó el ALGOL pues no lo podían implementar. Sin embargo, un brillante joven estudiante llamado Donald Knuth había implementado previamente el ALGOL-58 en una máquina anterior de Burroughs durante tres meses de verano. Muchos descartaron el ALGOL, creyendo equivocadamente que los lenguajes de alto nivel no podían tener la misma potencia que el ensamblador, y así no se dieron cuenta del potencial del ALGOL como lenguaje de programación de sistemas, una opinión no revisada hasta el desarrollo del lenguaje de programación C.

El compilador del ALGOL de Burroughs era muy rápido - éste impresionó al científico holandés Edsger Dijkstra cuando sometió un programa para ser compilado en la planta de Pasadena del B5000. Su mazo de tarjetas fue compilado casi inmediatamente y él quiso inmediatamente varias máquinas para su universidad (Universidad Técnica de Eindhoven) de regreso en Europa. El compilador era rápido por varias razones, pero la razón primaria era que era un "compilador de un solo paso" (one-pass compiler). Los computadores tempranos no tenían suficiente memoria para almacenar el código fuente, así que los compiladores (e incluso los ensambladores) usualmente necesitaban leer el código fuente más de una vez. La sintaxis del ALGOL requiere que cada variable (u otro objeto) sea declarada antes de ser usada, así que es factible escribir un compilador ALGOL que lea los datos solamente una vez. Este concepto tiene implicaciones teóricas profundas, pero también permite la compilación muy rápida. Los grandes sistemas de Burroughs podían compilar tan rápidamente como leían el código fuente de las tarjetas perforadas, y tenían los lectores de tarjetas más rápidos en la industria.

El poderoso compilador COBOL de Burroughs era también un compilador de un paso e igualmente rápido. Un programa COBOL de 4000 tarjetas se compilaba tan rápidamente como las 1000 tarjetas por minuto en que los lectores podían leer el código. El programa estaba listo para usarse tan pronto como las tarjetas pasaran a través del lector.

Originalmente, el sistema operativo MCP del B5000 fue escrito en una extensión ALGOL llamada Executive Systems Programming Oriented Language (ESPOL), (Lenguaje Orientado a la Programación de Sistemas Ejecutivos). A mediados de los años 1970 fue remplazado por un lenguaje llamado NEWP. Aunque NEWP probablemente solo significaba "New Programming language" (Nuevo Lenguaje de Programación), las leyendas rodean el nombre. Una historia común (quizás apócrifa) alrededor de Burroughs en ese entonces sugirió que el nombre viene de "No Executive Washroom Privileges" (No Privilegios al Servicio Ejecutivo). Otra historia es que aproximadamente en 1976, John McClintock de Burroughs (el ingeniero de software que desarrolló el NEWP) llamado el lenguaje "NEWP" después de que se le preguntó, otra vez, "¿ya tiene un nombre?": contestando "nyoooop" (no), él adoptó eso como un nombre. NEWP, era también un subconjunto de la extensión del ALGOL, pero fue más seguro que ESPOL, y eliminó algunas complejidades poco usadas del ALGOL. De hecho, todas las construcciones inseguras son rechazadas por el compilador NEWP a menos que haya un bloque específicamente marcado para permitir esas instrucciones. Estos bloques marcadores proporcionan un mecanismo de protección multi-nivel.

Los programas de NEWP que contienen construcciones inseguras son inicialmente no ejecutables. El administrador de seguridad de un sistema tienen la capacidad de "bendecir" tales programas y hacerlos ejecutables, pero los usuarios normales no pueden hacer esto. (Incluso los "usuarios privilegiados", quienes normalmente tienen privilegios de root, pueden no estar capacitados para hacer esto dependiendo de la configuración elegida por el sitio). Mientras NEWP puede ser usado para escribir programas generales y tiene un número de características diseñadas para los grandes proyectos de software, no soporta todo lo que hace ALGOL.

NEWP tiene un número de facilidades para permitir proyectos de software en grande, tales como el sistema operativo, incluyendo interfaces nombradas (funciones y datos), grupos de interfaces, módulos, y supermódulos. Los módulos agrupan datos y funciones juntos, permitiendo el fácil acceso a los datos como globales dentro del módulo. Las interfaces permiten a un módulo importar y exportar funciones y datos. Los supermódulos permiten que los módulos sean agrupados.

El segundo de nivel intermedio de seguridad entre el código del sistema operativo (en NEWP) y los programas de usuario (en ALGOL) es para los programas middleware, que son escritos en Data Comms ALGOL (DCALGOL). Esto se utiliza para la recepción y despacho de mensajes, que remueve mensajes los queues de entrada y los coloca en los queues para manejar otros procesos en el sistema. El middleware como COMS (introducido alrededor de 1984) recibe mensajes desde alrededor de la red y despacha estos mensajes a procesos de manejo específicos o a un Message Control System (MCS) (sistema de control de mensaje) como por ejemplo "Command AND Edit" (CANDE) (Comando y edita), el ambiente de desarrollo de programas.

Los MCS son elementos de software dignos de mención - ellos controlan las sesiones de usuario y proporcionan seguimiento del estado del usuario sin tener que correr procesos por usuario puesto que una sola pila de MCS puede ser compartido por muchos usuarios. El balance de carga también puede ser alcanzado a nivel del MCS. Por ejemplo diciendo que se quieren manejar 30 usuarios por pila, en este caso si se tienen 31 a 60 usuarios, se tendrán dos pilas, de 61 a 90 usuarios, tres pilas, etc. Esto da a las máquinas B5000 una gran ventaja de desempeño en un servidor puesto que no se necesita iniciar otro proceso de usuario y así crear una nueva pila cada vez que un usuario se conecta al sistema. Así que se pueden servir efectivamente los usuarios con los MCSs (independientemente de si requieren estado o no). Los MCSs también proporcionan la espina dorsal del procesamiento transaccional a gran escala.

El MCS hablaba con un coprocesador externo, el Terminal Control Processor (TCP) (procesador de control de terminal). Este era un minicomputador de 24 bits con una arquitectura de registro convencional y capacidad de hardware de entrada-salida para manejar miles de terminales remotos. El TCP y el B6500 se comunicaban por mensajes en memoria, esencialmente paquetes, en términos de hoy, y el MCS hacía el procesamiento de esos mensajes del lado del B6500. El TCP tenía un ensamblador, pero éste era el compilador ALGOL del B6500. Había una función del ALGOL para cada clase de instrucción del TCP, y si se llamara esa función entonces los correspondientes bits de instrucción TCP serían emitidos a la salida. Un programa TCP era un programa ALGOL que no abarcaba nada más que una lista larga de llamadas a estas funciones, una para cada declaración de lenguaje ensamblador. Esencialmente el ALGOL actuaba como el paso macro de un macro ensamblador. El primer paso era el compilador de ALGOL; el segundo paso corría el programa resultante (en el B6500) que entonces emitiría el binario para el TCP.

Otra variante del ALGOL es el Data Management ALGOL (DMALGOL) (ALGOL de gestión de datos). DMALGOL es ALGOL extendido para compilar el software de bases de datos DMSII desde los archivos de descripción de base de datos creados por el compilador DASDL. Los diseñadores y los administradores de base de datos compilan descripciones de base de datos para generar el código DMALGOL adaptado para las tablas y los índices especificados. Los administradores nunca necesitan escribir ellos mismos en DMALGOL. Los programas a nivel de usuario normales obtienen el acceso a la base de datos al usar el código escrito en lenguajes de aplicación, principalmente ALGOL y COBOL, extendidos con instrucciones de base de datos y directivas de tratamiento transaccional. La característica más notable de DMALGOL son sus mecanismos de procesamiento para generar el código para manejar las tablas y los índices.

El procesamiento de DMALGOL incluye variables y bucles, y puede generar nombres basados en variables de tiempo de compilación. Esto permite la adaptación mucho más allá de lo que puede ser hecho por facilidades de procesamiento que carecen bucles.

El DMALGOL es usado para proporcionar las rutinas de acceso adaptadas para las bases de datos DMSII. Después de que una base de datos es definida usando el Data Access and Structure Definition Language (DASDL) (Lenguaje de Definición Estructurado y de Acceso de Datos), el esquema es traducido por el preprocesador en rutinas adaptadas de acceso DMALGOL y después compilado. Esto significa que, a diferencia de otras implementaciones de DBMS, a menudo no hay necesidad de código if/then/else específico de base de datos en tiempo de ejecución. En los años 1970, estas "adaptaciones" fueron usadas muy extensivamente para reducir el tamaño y el tiempo de ejecución del código. Fue usado mucho menos en años posteriores, en parte porque el ajuste fino de bajo nivel para la memoria y la velocidad llegó a ser menos crítico, y en parte porque eliminando el preprocesamiento hace la codificación más simple y por lo tanto permitiendo optimizaciones más importantes.

En años posteriores, ya no siendo una preocupación el tamaño de código del compilador, la mayor parte de las construcciones de preprocesamiento fueron hechas disponibles en el nivel de usuario de ALGOL. Solamente las construcciones inseguras y el procesamiento directo del archivo de descripción de la base de datos permanecen restringidas a DMALGOL.

Roy Guck de Burroughs fue uno de los principales desarrolladores de DMSII.

Algunos de los detractores de la arquitectura B5000 creyeron que la arquitectura de pila era inherentemente lenta comparada con las arquitecturas basadas en registros. El truco para la velocidad del sistema es guardar los datos tan cerca al procesador como sea posible. En la pila del B5000, esto fue hecho asignando las dos posiciones superiores de la pila a dos registros, A y B. La mayoría de las operaciones son realizadas en esas dos posiciones del tope de la pila. En máquinas más rápidas después del B5000, una mayor parte de la pila se podía mantener en registros o un caché cerca del procesador.

Así los diseñadores de los sistemas B5000 actuales pueden optimizar en cualquier cosa que sea la última técnica, y los programadores no tienen que ajustar su código para que corra más rápido - incluso no necesitan recompilar, protegiendo así la inversión en software. Se sabe que algunos programas han corrido por años sobre muchas mejoras del procesador. Tales mejoras en velocidad son limitadas en las máquinas basadas en registros.

Otro punto para la velocidad, según lo promovido por los diseñadores RISC, era que la velocidad de procesador es considerablemente más rápida si todo está en un solo chip. Esto era un punto válido en los años 1970, cuando las arquitecturas más complejas tales como el B5000 requirieron demasiados transistores para caber en un solo chip. Sin embargo, éste no es el caso hoy en día, y cada máquina sucesora del B5000 ahora cabe en un solo chip, así como también las técnicas de soporte de desempeño tales como cachés y tuberías de instrucción (instruction pipelines).

De hecho, la línea Series A de sucesores del B5000 incluyó el primer mainframe en un simple chip, el Micro-A de finales de los años 1980. Este chip de "mainframe" (llamado Single-Chip A-series Mainframe Processor (SCAMP))descansaba en una tarjeta de circuito impreso enchufable basada en Intel.

Aquí hay un ejemplo de cómo los programas se mapean en la arquitectura de la pila

begin

   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
   — Éste es el nivel léxico 2 (el nivel cero es reservado para el sistema operativo
   — y el nivel 1 para los segmentos de código).
   — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

   — En el nivel 2 ponemos las variables globales para nuestro programa.

   integer i, j, k
   real f, g
   array a [0:9]

   procedure p (real p1, p2)
      value p1     — p1 pasó por valor, p2 pasó implícitamente por referencia.
      begin
         — — — — — — — — — — — — — — — — — —
         — Este bloque está en el nivel léxico 3
         — — — — — — — — — — — — — — — — — —
         real r1, r2

         r2 := p1 * 5
         p2 := r2  — Esto fija 'g' al valor de r2
         p1 := r2  — Esto fija 'p1' al valor de r2, pero no 'f'
         — Puesto que esto sobreescribe el valor original de f en p1, esto muy probablemente indica
         — un error. Pocos de los sucesores del ALGOL han corregido esta situación
         — haciendo los parámetros por valor como solo lectura – la mayoría no lo han hecho.

         if r2 > 10 then
            begin
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               — Una variable declarada aquí hace a éste el nivel léxico 4
               — — — — — — — — — — — — — — — — — — — — — — — — — — — —
               integer n

               — La declaración de una variable hace a esto un bloque, que invocará algún
               — código de construcción de pila. Normalmente, Ud. no declarará las variables aquí,
               — en tal caso esto sería una declaración compuesta, no un bloque.

               ... <== La pila de ejemplo está ejecutándose en alguna parte aquí
            end
      end

   .....

   p (f, g)
end

Cada stack frame (marco de pila) corresponde a un nivel léxico en el ambiente de ejecución actual. Como usted puede ver, el nivel léxico es el anidamiento textual estático de un programa, no el anidamiento de llamada dinámica. Las reglas de visibilidad del ALGOL, un lenguaje diseñado para compiladores de un solo paso, significa que solamente las variables declaradas antes de la posición actual son visibles en esa parte del código a excepción de declaraciones hacia adelante (forward declarations). Todas las variables declaradas en bloques de encerramiento son visibles. Otro caso es que las variables del mismo nombre pueden ser declaradas en bloques internos y éstas efectivamente ocultan a las variables externas que llegan a ser inaccesibles.

Puesto que el anidamiento léxico es estático, es muy raro encontrar a un programa anidado más de cinco niveles de profundidad, y podría argüirse que tales programas serían pobremente estructurados. Las máquinas B5000 permiten el anidamiento de hasta 32 niveles. Los procedimientos pueden ser invocados de cuatro maneras - normal, llamada, proceso, y ejecución.

Un procedimiento es llamado de la manera normal en que cualquier lenguaje invoca una rutina, suspendiendo la rutina que llama hasta que el procedimiento invocado retorne.

El mecanismo de llamada invoca a un procedimiento como corrutina. Las corrutinas tienen tareas asociadas, donde el control es pasado explícitamente entre las tareas por medio de una instrucción CONTINUE. Estos son procesos síncronos.

El mecanismo de proceso invoca a un procedimiento como una tarea asíncrona y en este caso una pila separada es iniciada comenzando en el nivel léxico del procedimiento procesado. Como la tarea es asíncrona, a diferencia de las corrutinas, no hay manera de saber exactamente cuando el control será pasado entre las tareas. Note también que el procedimiento procesado todavía tiene acceso al ambiente de encerramiento y esto es un mecanismo muy eficiente de comunicación entre procesos (Inter Process Communication (IPC)). Puesto que dos o más tareas tienen ahora acceso a las variables comunes, las tareas deben ser sincronizadas para prevenir condiciones de carrera, que es manejado por el tipo de datos EVENT (evento), donde los procesos pueden esperar (WAIT) en un evento hasta que sean causados por otro proceso cooperativo. Los eventos también permiten la sincronización de exclusión mutua a través de las funciones PROCEDURE y LIBERATE. Si por cualquier razón la tarea hija muere, la tarea que llama puede continuar - sin embargo, si muere el proceso padre, entonces todos los procesos hijo son terminados automáticamente. En una máquina con más de un procesador, los procesos pueden correr simultáneamente. Este mecanismo de evento es un activador básico para el multiprocesamiento además de la multitarea.

El último tipo de invocación es la ejecución. Esto hace correr a un procedimiento como una tarea independiente que pueda continuar después de que el proceso que la originó termine. Por esta razón, el proceso hijo no puede tener acceso a variables en el ambiente del padre, y todos los parámetros pasajeros al procedimiento invocado deben ser llamados por valor.

Así el Burroughs Extended ALGOL tenía todas las características del multiprocesamiento y sincronización de lenguajes posteriores como el Ada, con el beneficio adicional que el soporte para los procesos asíncronos fue incorporado a nivel del hardware.

Una última posibilidad es que un procedimiento pueda ser declarado INLINE (en línea), eso es cuando el compilador ve una referencia a él, y el código para el procedimiento es generado en línea para ahorrar los gastos indirectos de una llamada de procedimiento. Esto es hecho mejor para pequeñas partes de código y es como una definición, excepto que usted no consiga los problemas con los parámetros que usted pueda con las definiciones. Esta facilidad está disponible en NEWP.

En el programa de ejemplo solamente son usadas las llamadas normales, así que toda la información estará en una sola pila. Para las llamadas asíncronas, la pila estaría dividida en múltiples pilas de modo que los procesos compartan datos pero corran asíncronamente.

Una cosa agradable de la estructura de la pila es que si un programa falla, es tomada una descarga de la pila y es muy fácil para un programador descubrir exactamente cuál era el estado del programa cuando estaba corriendo. Compare eso a los vaciados de memoria (memory dumps) y el intercambio de paquetes de otros sistemas.

Otra cosa acerca de la estructura de la pila es que los programas son implícitamente recursivos. El FORTRAN no era una lenguaje recursivo y era quizás un obstáculo a la comprensión de la gente, de cómo el ALGOL debía ser implementado para tener recursión. En el B5000, esto no era un problema - de hecho, tenían el problema reverso, cómo evitar que los programas fueran recursivos. Al la final ellos no le prestaron atención, incluso el compilador FORTRAN de Burroughs era recursivo, puesto que era improductivo pararlo para que no fuera así.

Así el FORTRAN de Burroughs fue mejor que cualquier otra implementación de FORTRAN.^{[cita requerida]} de hecho, Burroughs comenzó a ser conocido por sus superiores compiladores e implementaciones de lenguajes, incluyendo el orientado a objetos Simula (un sobreconjunto del ALGOL), y Kenneth Iverson, el diseñador del APL, declaró que la implementación de Burroughs del APL era la mejor que él había visto.^{[cita requerida]} Por otro lado, John McCarthy, el diseñador del lenguaje LISP, discrepó, puesto que el LISP fue basado en código modificable,^{[cita requerida]} a él no le gustaba el código no modificable del B5000,^{[cita requerida]} pero de todos modos la mayoría de las implementaciones del LISP correrían en un ambiente interpretativo.

Observe también que las pilas automáticamente usan tanta memoria como es necesaria para un proceso. No había que hacer SYSGENs en los sistemas de Burroughs, como con los sistemas de la competencia, para preconfigurar las particiones de la memoria en las cuales correrían las tareas. De hecho, Burroughs era realmente campeón en "plug and play" en el sentido que los periféricos adicionales se podían enchufar en el sistema sin tener que recompilar el sistema operativo con nuevas tablas de periféricos. Así estas máquinas podían verse como los precursores de los dispositivos de hoy como el USB y el firewire.