Grandes sistemas de Burroughs , la enciclopedia libre

Los grandes sistemas de Burroughs fueron los más grandes de tres series de computadores mainframes de Burroughs Corporation. Fundada en los años 1880, Burroughs era la más vieja entidad que continuaba operando en el área de la computación, pero hacia finales de la década de 1950, su equipo de computación todavía estaba limitado a las máquinas de contabilidad electromecánicas tales como la Sensimatic; las cuales no tenían nada para competir con sus rivales tradicionales como IBM y NCR que habían comenzado a producir computadores de mayor escala, o con la recientemente fundada UNIVAC. La primera máquina, el B5000, fue diseñada en 1961 y Burroughs buscaba resolver su tardía entrada en el mercado con la estrategia de un diseño completamente diferente, basado en las más avanzadas ideas computacionales disponibles en ese tiempo. Los computadores que han usado esta arquitectura todavía estaban en producción en 2010 como las máquinas ClearPath/MCP de Unisys. Ahora, Unisys usa los procesadores Intel Xeon, y corre en sus servidores los sistemas operativos MCP, Microsoft Windows y Linux.

El primer miembro de la serie, el B5000, fue diseñado a principios de 1961 por un equipo de ingenieros bajo la dirección de Robert (Bob) Barton. Fue una máquina única, muy adelantada a su tiempo. Ha sido listada por el influyente arquitecto de computadores John Mashey como una de las arquitecturas que más admira. "Yo siempre pensé que era uno de los más innovadores ejemplos de diseño combinado de hardware/software que haya visto, y mucho más adelantado a su tiempo".^[1]​

• Todo el código es automáticamente reentrante (La figura 4.5 de la Monografía ACM muestra en pocas palabras el por qué): los programadores no tienen que hacer nada, sino solo usar los dos simples primitivos mostrados, para tener cualquier código en cualquier lenguaje de programación distribuido a través de los procesadores. Este es quizás el canónico, pero no significa el único beneficio de estas importantes características que distinguen a esta arquitectura:
  • Arquitectura data-driven tagged y basada en descriptor
  • El hardware fue diseñado para soportar los requerimientos del software
  • El hardware diseñado para soportar exclusivamente lenguajes de programación de alto nivel
  • No hay lenguaje ensamblador o assembler; todo el software del sistema está escrito en una variedad extendida de ALGOL
  • No hay registros accesibles al programador
  • Conjunto de instrucciones simplificado
  • Arquitectura de Pila (para soportar lenguajes algorítmicos de alto nivel)
  • Soporte para sistema operativo de alto nivel (Master Control Program)
• Soporte para multiprocesamiento maestro/esclavo
• Soporte para otros lenguajes como COBOL
• Manipulaciones poderosas de cadenas de caracteres
• Arquitectura segura prohibiendo acceso no autorizado a datos o disrupciones de operaciones
• Temprana detección de error soportando el desarrollo y las pruebas (testing) de software
• La primera implementación comercial de la memoria virtual
• Los sucesores todavía existen en las máquinas ClearPath/MCP de Unisys
• Influenció muchas de las técnicas computacionales de hoy

En el texto siguiente, las designaciones de la máquina, B5000, Serie A, y ClearPath/MCP son usadas intercambiablemente aunque éstas combinan innecesariamente las características y conceptos de varias máquinas y deberán ser corregidas algún día para mantener claramente las distinciones entre el 5000, 5500, 6500 y secuencia, y la Serie A.

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.

El primero de los grandes sistemas de Burroughs fue el B5000. Diseñado en 1961, era un computador de segunda generación usando lógica de transistor discreto y memoria de núcleo magnético. Las máquinas sucesoras siguieron las tendencias de desarrollo de hardware para reimplementar la arquitectura en nueva lógica durante los próximos 25 años, con el B5500, B6500, B5700, B6700, B7700, B6800, B7800, y finalmente la Serie A de Burroughs. Después de que Burroughs se convirtió en parte de Unisys, Unisys continuó desarrollando nuevas máquinas basadas en el MCP CMOS ASIC. Estas máquinas iban desde el Libra 100 hasta el Libra 500, con el Libra 590 siendo anunciado en el año 2005. Posteriores Libras, incluyendo el 590, también incorporaron los procesadores Intel Xeon y pueden correr la arquitectura de grandes sistemas de Burroughs en emulación así como en los procesadores MCP CMOS. No está claro si Unisys continuará el desarrollo de nuevos MCP CMOS ASICs.

Los grandes sistemas de Burroughs implementaron una arquitectura de pila derivada del ALGOL, a diferencia de arquitecturas lineares tales como las del PDP-11, Motorola M68k, e Itanium y arquitecturas segmentadas como x86 y Texas Instruments. (Esto se refiere a la disposición de la memoria y cómo un programa la usa).

Mientras que el B5000 fue diseñado específicamente alrededor del ALGOL, esto fue solamente un punto de partida. Otros lenguajes orientados a los negocios como COBOL también eran bien soportados, más notablemente por los poderosos operadores de string que fueron incluidos para el desarrollo de compiladores rápidos.

El ALGOL usado en el B5000 es un subconjunto extendido del ALGOL. Incluye poderosas instrucciones de manipulación de string pero excluye ciertas construcciones del ALGOL, notablemente los parámetros formales no especificados. Un mecanismo DEFINE responde a un propósito similar a los #defines encontrados en C, pero está completamente integrado en el lenguaje en lugar de ser un preprocesador. El tipo de datos EVENT facilita la coordinación entre los procesos, y los bloques ON FAULT activan el manejo de fallas del programa.

El nivel de usuario del ALGOL no incluye muchas de las construcciones inseguras necesarias por el sistema operativo u otro software de sistema. Dos niveles de extensiones del lenguaje proporcionan las construcciones adicionales: ESPOL y NEWP para escribir el MCP y el software estrechamente relacionado, y DCALGOL y DMALGOL para proporcionar extensiones más específicas para las clases específicas de software de sistema.

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.

En muchos de los primeros sistemas y lenguajes, a menudo se les decía a los programadores que no hicieran sus rutinas demasiado pequeñas porque las llamadas y retornos de procedimiento eran operaciones costosas, tenían que ser realizados un número de operaciones para mantener el pila. El B5000 fue diseñado como una máquina de pila - todos los datos del programa eran guardados en la pila a excepción de los arreglos (que incluyen strings y objetos). Esto significó que las operaciones de la pila fueron optimizadas para la eficacia. Como una máquina orientada a pila, no había registros direccionables para el programador.

La multitarea también era muy eficiente en las máquinas B5000. Hay una instrucción específica para realizar cambios de proceso - MVST (mueve pila).^[6]​ Cada pila representa un proceso (una tarea o un hilo) y las tareas pueden resultar bloqueadas esperando peticiones de recursos (que incluye esperar a un procesador para correr en él si la tarea ha sido interrumpida debido a la multitarea preemptiva). Los programas de usuario no pueden realizar un MVST, y en el sistema operativo hay solamente una línea de código donde es hecho esto.

Así que un cambio de proceso procede algo similar a esto - un proceso pide un recurso que no está disponible inmediatamente, quizá una lectura de un registro de un archivo desde un bloque que no está actualmente en memoria, o el temporizador del sistema (timer) ha disparado una interrupción. Entonces se entra al código del sistema operativo y corre encima de la pila del usuario. Apaga los temporizadores del proceso del usuario. El proceso actual es puesto en la cola (queue) apropiada para el recurso pedido, o la cola esperando por el procesador si esto es un cambio de contexto preemtivo. El sistema operativo determina el primer proceso en la cola e invoca la instrucción move_stack, que hace al proceso en la cabeza de la cola activo.

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

El aspecto más definitorio del B5000 es que es una máquina de pila según lo tratado arriba. Sin embargo, otras dos características muy importantes de la arquitectura son que está basada en etiquetas (tags) y descriptores.

En el B5000 original, existía un bit en cada palabra para identificarla como una palabra de código o de datos. Esto era un mecanismo de seguridad para parar programas que pudieran corromper código, de la manera en que lo hacen hoy los crackers.

Una ventaja para el código inmodificable es que el código B5000 es completamente reentrante: no importa cuántos usuarios están corriendo un programa, siempre habrá solamente una copia del código en memoria, así ahorrando una cantidad sustancial de memoria; estas máquinas eran realmente muy eficientes en el uso de la memoria y el disco.

Más adelante, cuando el B6500 fue diseñado, se dieron cuenta de que la distinción de 1 bit entre el código y los datos era una idea poderosa y fue extendida a tres bits fuera de la palabra de 48 bits para formar una etiqueta (tag). Los bits de datos están en los bits 0-47 y la etiqueta está en los bits 48-50. El bit 48 era de solo lectura, así las etiquetas impares indicaban palabras de control que no se podían escribir por un programa de nivel de usuario. A las palabras del código se les dieron la etiqueta 3. Aquí hay una lista de las etiquetas y de su función:

Nota: Internamente, algunas de las máquinas tenían palabras de 60 bits, con los bits adicionales usados para propósitos de ingeniería como por ejemplo un campo de corrección de error de código Hamming, pero éstos nunca fueron vistos por los programadores.

Nota: La encarnación actual de estas máquinas, el Unisys ClearPath ha extendido las etiquetas a cuatro bits. El nivel de microcódigo que especificaba etiquetas de cuatro bit fue referido como nivel Gamma.

Las palabras marcadas (etiquetadas) con números pares son datos de usuario que pueden ser modificados por un programa de usuario como un estado de usuario. las palabras marcadas con números impares son creadas y usadas directamente por el hardware y representan un estado de ejecución del programa. Puesto que estas palabras son creadas y consumidas por instrucciones específicas o el hardware, el formato exacto de estas palabras puede cambiar con la implementación del hardware y los programas de usuario no necesitan ser recompilados, puesto que el mismo flujo del código producirá los mismos resultados, aunque el formato de la palabra del sistema pudiera haber cambiado.

Las palabras con etiqueta 1 representan direcciones de datos en el stack. El normal IRW simplemente almacena una pareja de direcciones a los datos en la pila actual. La SIRW referencia datos en cualquier pila al incluir un número de pila en la dirección.

Las palabras con etiqueta 5 son los descriptores, que son descritos más completamente en la siguiente sección. Las palabras de etiqueta 5 representan direcciones de datos fuera del stack.

La etiqueta 7 es la palabra de control de programa (PCW) que describe un punto de entrada del procedimiento. Cuando los operadores encuentran un PCW, se entra en el procedimiento. El operador ENTR explícitamente entra en un procedimiento (rutina sin valor de retorno). Las funciones (rutinas con valor de retorno) son implícitamente entradas por los operadores tales como llamada de valor (VALC). Note que las rutinas globales están almacenadas en los ambientes D[2] como SIRWs que apuntan a un PCW almacenado en el diccionario del segmento de código en el ambiente D[1]. El ambiente de D[1] no es almacenado en el stack actual porque puede ser referenciado por todos los procesos que comparten este código. Así el código es reentrante y compartido.

La etiqueta 3 representa palabras de código en sí mismas, que no ocurrirán en el stack. La etiqueta 3 es también usada para las palabras de control del stack MSCW, RCW, TOSCW.

La figura a la izquierda muestra cómo la arquitectura de los sistemas grandes de Burroughs era fundamental una arquitectura de hardware para la programación orientada a objetos, algo que todavía no existe en arquitecturas convencionales.

Indudablemente, hay influencia directa del B5000 en la gama actual del rango de mainframes ClearPath de Unisys, que son los descendientes directos del B5000 y todavía tienen el sistema operativo MCP después de 40 años de desarrollo consistente. Ahora la esta arquitectura es llamada emode (por modo de emulación), puesto que la arquitectura B5000 puede ser implementada en muchas plataformas. También iba a estar un nmode (modo nativo), pero este fue eliminado,^{[cita requerida]} así que a menudo se puede oír que las máquinas sucesoras del B5000 son referidas como "máquinas emode".

Las máquinas B5000 fueron programadas exclusivamente en lenguajes de alto nivel, no hay ensamblador, obviamente esto no se aplicaría al emode, el cual es entrado para correr en el hardware base y rompe así la base fundamental de la arquitectura arriba indicada excepto cuando se indica abajo.

La arquitectura de pila del B5000 inspiró a Chuck Moore, el diseñador del lenguaje de programación Forth, quien encontró al B5500 mientras estaba en el MIT. En Forth - The Early Years, Moore describió la influencia, observando que las instrucciones DUP, DROP y SWAP del Forth vinieron de las instrucciones correspondientes del B5500 (DUPL, DLET, EXCH).

Los sistemas de Hewlett-Packard (HP) fueron influenciados por el B5000, puesto que algunos ingenieros de Burroughs encontraron luego un empleo diseñando máquinas para HP y éstas también eran máquinas de pila. El trabajo de Bob Barton sobre la notación polaca inversa (RPN) encontró su camino en las calculadoras HP comenzando con la HP 9100A, y notablemente la HP-35 y las calculadoras subsecuentes.

Los sistemas NonStop diseñados por Tandem Computers a finales de los años 1970 y principios de los 1980 eran también máquinas de pila, influenciadas por el B5000 indirectamente a través de la conexión con HP, ya que varios de los primeros ingenieros de Tandem venían de HP. Alrededor 1990, estos sistemas migraron a una arquitectura RISC y ahora contienen solamente peculiares vestigios de su arquitectura de pila.

Bob Barton era también muy influyente en Alan Kay. Kay también fue impresionado por la arquitectura data-driven tagged del B5000 y esto influenció su pensamiento en sus desarrollos de la programación orientada a objetos y el Smalltalk.

Otra faceta de la arquitectura B5000 fue que era una arquitectura segura que corría directamente en el hardware. Esta técnica tiene descendientes en las máquinas virtuales de hoy en sus tentativas de proporcionar ambientes seguros. Un notable producto es la máquina virtual de Java, que proporciona una caja de arena segura en la cual corren las aplicaciones.

El valor de la arquitectura de hardware atando lo que existió antes del emode sería substancialmente preservado en el Intel iAPXx86 hasta el punto que el MCP fuera el único programa de control pero el soporte proporcionado por los hardwares comunes sigue siendo inferior al del modo nativo. Una arquitectura de procesador Intel poco conocida que realmente precedió al iAPXx86 (el Intel iAPX 432) había proporcionado una base física equivalente, puesto que esencialmente también era una arquitectura de flujo de datos orientada al objeto.

• Barton, Robert S. "A New Approach to the Functional Design of a Digital Computer" Proceedings of the Western Joint Computer Conference. ACM (1961).
• Charles Babbage Institute, Burroughs B 5000 Conference, University of Minnesota, Minneapolis. The Burroughs 5000 computer series is discussed by individuals responsible for its development and marketing from 1957 through the 1960s in a 1985 conference sponsored by AFIPS and Burroughs Corporation.
• Gray, George. "Some Burroughs Transistor Computers", Unisys History Newsletter, Volume 3, Number 1, March 1999.
• Gray, George. "Burroughs Third-Generation Computers, Unisys History Newsletter, Volume 3, Number 5, October 1999.
• Hauck, E.A., Dent, Ben A. "Burroughs B6500/B7500 Stack Mechanism", SJCC (1968) pp. 245-251.
• McKeeman, William M. "Language Directed Computer Design", Fall Joint Computer Conference, (1967) pp.413-417.
• Organick, Elliot I. "Computer System Organization The B5700/B6700 series", Academic Press (1973)
• Waychoff, Richard, "Stories of the B5000 and People Who Were There", 27 de septiembre de 1979

• Burroughs
• Máquina de pila
• Lenguaje de programación orientado a pila
• Forth