Sistemas grandes de Burroughs

• El hardware fue diseñado para dar soporte a los requisitos del software.
• Hardware diseñado para soportar exclusivamente lenguajes de programación de alto nivel.
• Conjunto de instrucciones simplificado
• No se utiliza lenguaje ensamblador ni ensamblador; todo el software del sistema está escrito en una variante extendida de ALGOL 60 denominada ESPOL . Sin embargo, ESPOL contiene instrucciones para cada una de las sílabas de la arquitectura.
• Diseño parcialmente basado en datos, etiquetado y descriptor.
• Pocos registros accesibles para el programador
• Máquina de pila donde todas las operaciones utilizan la pila en lugar de operandos explícitos. Este enfoque ha caído en desuso.
• Todas las interrupciones y llamadas a procedimientos utilizan la pila.
• Compatibilidad con otros lenguajes como COBOL.
• Manipulación de cuerdas potente
• Todo el código es automáticamente reentrante : los programadores no tienen que hacer nada más para que cualquier código en cualquier lenguaje se distribuya entre procesadores que usar solo las dos primitivas simples que se muestran.
• Soporte para un sistema operativo (MCP, Programa de Control Maestro )
• Compatibilidad con multiprocesamiento asimétrico (maestro/esclavo)
• Un intento de arquitectura segura que prohíba el acceso no autorizado a los datos o las interrupciones de las operaciones ^{[ NB 2 ]}
• Detección temprana de errores que facilita el desarrollo y las pruebas de software.
• Una implementación comercial de memoria virtual, precedida únicamente por el Ferranti Atlas .
• Primer modelo de memoria segmentada

Soporte de idiomas

El B5000 fue diseñado para soportar exclusivamente lenguajes de alto nivel. Esto ocurrió en una época en la que dichos lenguajes comenzaban a ganar popularidad con FORTRAN y posteriormente COBOL . Algunos consideraban que FORTRAN y COBOL eran lenguajes menos robustos en comparación con las técnicas de software modernas, por lo que se adoptó un lenguaje más reciente y prácticamente sin probar: ALGOL-60 . El dialecto de ALGOL elegido para el B5000 fue Elliott ALGOL , diseñado e implementado por primera vez por CAR Hoare en un Elliott 503. Esta fue una extensión práctica de ALGOL con instrucciones de E/S (que ALGOL había ignorado) y potentes instrucciones de procesamiento de cadenas. La famosa conferencia de Hoare al recibir el Premio Turing versó sobre este tema.

Así pues, la B5000 se basaba en un lenguaje muy potente. Donald Knuth había implementado previamente ALGOL 58 en una máquina Burroughs anterior durante los tres meses de sus vacaciones de verano, y participó indirectamente en el diseño de la B5000 como consultor. Muchos descartaron ALGOL, creyendo erróneamente que los lenguajes de alto nivel no podían tener la misma potencia que el ensamblador, y por lo tanto no comprendieron el potencial de ALGOL como lenguaje de programación de sistemas .

El compilador ALGOL de Burroughs era muy rápido , lo que impresionó al científico holandés Edsger Dijkstra cuando presentó un programa para ser compilado en la planta B5000 de Pasadena. Su mazo de cartas se compiló casi de inmediato y enseguida quiso varias máquinas para su universidad, la Universidad Tecnológica de Eindhoven en los Países Bajos. El compilador era rápido por varias razones, pero la principal era que era un compilador de una sola pasada . Los primeros ordenadores no tenían suficiente memoria para almacenar el código fuente, por lo que los compiladores (e incluso los ensambladores) solían necesitar leer el código fuente más de una vez. La sintaxis ALGOL de Burroughs, a diferencia del lenguaje oficial, requiere que cada variable (u otro objeto) se declare antes de su uso, por lo que es factible escribir un compilador ALGOL que lea los datos solo una vez. Este concepto tiene profundas implicaciones teóricas, pero también permite una compilación muy rápida. Los grandes sistemas de Burroughs podían compilar tan rápido como leían el código fuente de las tarjetas perforadas , y contaban con los lectores de tarjetas más rápidos del sector.

El potente compilador COBOL de Burroughs también era de una sola pasada e igual de rápido. Un programa COBOL para 4000 tarjetas se compilaba tan rápido como los lectores, con una capacidad de 1000 tarjetas por minuto, podían leer el código. El programa estaba listo para usarse en cuanto las tarjetas pasaban por el lector.

Originalmente, el sistema operativo B5000 MCP fue escrito en una extensión de ALGOL extendida llamada ESPOL ( Executive Systems Programming Oriented Language ). Este superconjunto de ALGOL 60 proporcionó capacidades de lo que más tarde se denominaría un lenguaje de programación de sistemas ^{[ 24 ]} o lenguaje de alto orden orientado a la máquina (mohol), como la interrupción de un procesador en un sistema multiprocesador (los grandes sistemas de Burroughs eran sistemas multiprocesador). ESPOL se utilizó para escribir el Programa de Control Maestro (MCP) en los sistemas informáticos de Burroughs desde el B5000 hasta el B6700. ^{[ 25 ] [ 26 ] [ 27 ]} El compilador de una sola pasada para ESPOL podía compilar más de 250 líneas por segundo.

Esto fue reemplazado a mediados o finales de los 70 por un lenguaje llamado NEWP. Aunque NEWP probablemente significaba simplemente "Nuevo lenguaje de programación", existen leyendas en torno al nombre. Una historia común (quizás apócrifa) dentro de Burroughs en ese momento sugería que provenía de " No Executive Washroom Privileges " (Sin privilegios de baño ejecutivo). Otra historia cuenta que, alrededor de 1976, John McClintock de Burroughs (el ingeniero de software que desarrollaba NEWP) nombró al lenguaje "NEWP" después de que le preguntaran, una vez más, "¿ya tiene nombre?": respondiendo "nyoooop", lo adoptó como nombre. NEWP también era una extensión de ALGOL, pero era más seguro que ESPOL y eliminaba algunas complejidades poco utilizadas de ALGOL. De hecho, el compilador de NEWP rechaza todas las construcciones inseguras a menos que un bloque esté marcado específicamente para permitir esas instrucciones. Dicha marcación de bloques proporciona un mecanismo de protección multinivel.

Los programas NEWP que contienen construcciones inseguras no son ejecutables inicialmente. El administrador de seguridad del sistema puede autorizar la ejecución de dichos programas, pero los usuarios normales no pueden hacerlo. (Incluso los usuarios con privilegios, que normalmente tienen privilegios de administrador, podrían no poder hacerlo dependiendo de la configuración del sitio). Si bien NEWP se puede usar para escribir programas generales y cuenta con varias funciones diseñadas para grandes proyectos de software, no es compatible con todas las funcionalidades de ALGOL.

NEWP cuenta con diversas herramientas para facilitar proyectos de software a gran escala, como el sistema operativo, incluyendo interfaces con nombre (funciones y datos), grupos de interfaces, módulos y supermódulos. Los módulos agrupan datos y funciones, permitiendo un acceso sencillo a los datos de forma global dentro del módulo. Las interfaces permiten importar y exportar funciones y datos dentro de un módulo. Los supermódulos permiten agrupar módulos.

En la implementación original, el sistema utilizaba un procesador de comunicaciones de datos (DCP) especializado para gestionar la entrada y salida de mensajes desde y hacia dispositivos remotos. Se trataba de un miniordenador de 24 bits con una arquitectura de registro convencional y capacidad de E/S de hardware para gestionar miles de terminales remotos. El DCP y el B6500 se comunicaban mediante mensajes en memoria, esencialmente paquetes en términos actuales, y el MCS se encargaba del procesamiento de esos mensajes en el lado del B6500. En sus inicios, el DCP contaba con un ensamblador (Dacoma), un programa de aplicación llamado DCPProgen escrito en ALGOL del B6500. Posteriormente, el compilador NDL (Network Definition Language) generaba el código DCP y el archivo de definición de red (NDF). Finalmente, una actualización posterior dio lugar al desarrollo del lenguaje y compilador NDLII, que se utilizaron junto con los DCP de los modelos 4 y 5. Existía una función ALGOL para cada tipo de instrucción DCP, y al llamar a dicha función, los bits de instrucción DCP correspondientes se emitían a la salida. Un programa DCP era un programa ALGOL que consistía únicamente en una larga lista de llamadas a estas funciones, una por cada instrucción en lenguaje ensamblador. En esencia, ALGOL actuaba como la fase de macros de un ensamblador de macros. La primera fase era el compilador ALGOL; la segunda fase consistía en ejecutar el programa resultante (en el B6500), que luego generaba el binario para el DCP.

A principios de la década de 1980, la tecnología DCP fue reemplazada por el ICP (Procesador de Comunicaciones Integrado), que proporcionaba conectividad LAN para el sistema mainframe. Los dispositivos remotos, así como los servidores/mainframes remotos, se conectaban a la red mediante dispositivos independientes denominados CP2000. Los CP2000 fueron diseñados para brindar soporte a los nodos de red en una red distribuida, donde los nodos se conectaban mediante la tecnología de red BNAV2 (Arquitectura de Red Burroughs Versión 2). BNAV2 era el equivalente funcional de Burroughs al producto IBM SNA y admitía la interoperabilidad con entornos IBM en los modos de transporte PUT2 y PUT5. El cambio en el hardware externo de comunicaciones de datos no requirió ninguna modificación del software MCS (Sistema de Control de Mensajes, que se describe más adelante).

Al recibir mensajes, estos se transmitían desde el DCP a través de un bus interno a la pila de procesos DCP del MCP Datacom Control (DCC). Se iniciaba un proceso DCC por cada DCP configurado en el sistema. La pila de procesos DCP se encargaba de que el mensaje entrante se pusiera en cola para su entrega al MCS designado para gestionar el tráfico del dispositivo de origen y devolviera cualquier respuesta al DCP para su entrega al dispositivo de destino. Desde el punto de vista del procesamiento, no se requerían cambios en el software del MCS para gestionar los diferentes tipos de hardware de puerta de enlace, ya fueran los 5 estilos de DCP, el ICP o las combinaciones ICP/CP2000.

Además de ser un servicio de entrega de mensajes, un MCS constituye un nivel intermedio de seguridad entre el código del sistema operativo (en NEWP) y los programas de usuario (en ALGOL u otros lenguajes de aplicación, como COBOL, FORTRAN y, posteriormente, JAVA). Un MCS puede considerarse un programa de middleware y está escrito en DCALGOL (Data Communications ALGOL). Como se mencionó anteriormente, el MCS recibía mensajes de las colas gestionadas por la Datacom Control Stack (DCC) y los reenviaba a la aplicación o función correspondiente para su procesamiento. Uno de los primeros MCS fue CANDE (Command AND Edit), desarrollado como entorno de desarrollo de programas en línea. La Universidad de Otago en Nueva Zelanda desarrolló un entorno de desarrollo de programas similar a CANDE, denominado SCREAM/6700, al mismo tiempo que IBM ofrecía un servicio remoto de tiempo compartido y desarrollo de programas conocido como CALL/360, que se ejecutaba en sistemas IBM serie 360. Otro MCS, llamado COMS, se introdujo alrededor de 1984 y se desarrolló como un sistema de control de procesamiento de transacciones de alto rendimiento . Existían entornos de procesamiento de transacciones predecesores, como GEMCOS (Sistema de Control de Mensajes Generalizado), y una filial australiana de Burroughs desarrolló un sistema de control de transacciones llamado TPMCS (Sistema de Control de Transacciones). Estos sistemas de control de transacciones permitían la entrega de datos de aplicaciones a entornos de producción en línea y el envío de respuestas a usuarios, dispositivos y sistemas remotos.

Los MCS son componentes de software dignos de mención: controlan las sesiones de usuario y permiten realizar un seguimiento del estado del usuario sin necesidad de ejecutar procesos individuales, ya que una única pila MCS puede ser compartida por varios usuarios. El balanceo de carga también se puede lograr a nivel de MCS. Por ejemplo, si se desea gestionar 30 usuarios por pila, se necesitarán dos pilas para entre 31 y 60 usuarios, tres pilas para entre 61 y 90 usuarios, etc. Esto proporciona a las máquinas B5000 una gran ventaja de rendimiento en un servidor, ya que no es necesario iniciar un nuevo proceso de usuario ni crear una nueva pila cada vez que un usuario se conecta al sistema. De esta forma, se puede brindar un servicio eficiente a los usuarios (independientemente de si requieren o no información de estado) con los MCS. Los MCS también constituyen la base del procesamiento de transacciones a gran escala.

Hacia 1988, se desarrolló una implementación de TCP/IP principalmente para un cliente del gobierno estadounidense, utilizando el procesador de comunicaciones distribuidas CP2000 como host del protocolo. Dos o tres años después, la implementación de TCP/IP se reescribió para basarse en la arquitectura host/servidor, con mejoras significativas en rendimiento y funcionalidad. En ese mismo período, se implementó la pila de protocolos OSI, principalmente en el CP2000, pero se implementó una amplia infraestructura de soporte en el sistema principal. Se implementaron todas las aplicaciones definidas por el estándar OSI, incluyendo el alojamiento de correo X.400 y los servicios de directorio X.500.

Otra variante de ALGOL es DMALGOL (Data Management ALGOL). DMALGOL es una extensión de ALGOL para compilar el software de base de datos DMSII a partir de archivos de descripción de base de datos creados por el compilador DASDL (Data Access and Structure Definition Language). Los diseñadores y administradores de bases de datos compilan las descripciones de la base de datos para generar código DMALGOL adaptado a las tablas e índices especificados. Los administradores no necesitan escribir código DMALGOL. Los programas de usuario normales acceden a la base de datos mediante código escrito en lenguajes de aplicación, principalmente ALGOL y COBOL, extendido con instrucciones de base de datos y directivas de procesamiento de transacciones. La característica más destacada de DMALGOL son sus mecanismos de preprocesamiento para generar código para el manejo de tablas e índices.

El preprocesamiento de DMALGOL incluye variables y bucles, y puede generar nombres basados ​​en variables de tiempo de compilación. Esto permite una personalización mucho mayor que la que ofrecen las herramientas de preprocesamiento que carecen de bucles.

DMALGOL se utiliza para proporcionar rutinas de acceso personalizadas para bases de datos DMSII . Una vez definida la base de datos mediante el Lenguaje de Definición de Estructura y Acceso a Datos (DASDL), el preprocesador traduce el esquema a rutinas de acceso DMALGOL personalizadas y, posteriormente, lo compila. Esto significa que, a diferencia de otras implementaciones de sistemas de gestión de bases de datos (DBMS), a menudo no es necesario código condicional (if/then/else) específico de la base de datos en tiempo de ejecución. En la década de 1970, esta "personalización" se utilizó ampliamente para reducir el tamaño del código y el tiempo de ejecución. Su uso disminuyó considerablemente en años posteriores, en parte porque la optimización de bajo nivel para la memoria y la velocidad se volvió menos crítica, y en parte porque la eliminación del preprocesamiento simplificó la codificación y, por lo tanto, permitió optimizaciones más importantes.

Una versión de ALGOL para aplicaciones, que permite el acceso a bases de datos desde programas de aplicación, se denomina BDMSALGOL e incluye verbos como "FIND", "LOCK", "STORE", "GET" y "PUT" para el acceso a bases de datos y la manipulación de registros. Además, se implementaron los verbos "BEGINTRANSACTION" y "ENDTRANSACTION" para resolver la situación de interbloqueo que se produce cuando varios procesos acceden y actualizan las mismas estructuras.

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

En años posteriores, al reducirse el tamaño del código del compilador, la mayoría de las construcciones de preprocesamiento se pusieron a disposición del usuario de ALGOL. Solo las construcciones no seguras y el procesamiento directo del archivo de descripción de la base de datos siguen restringidos a DMALGOL.

El rendimiento de la pila se consideraba lento en comparación con las arquitecturas basadas en registros; por ejemplo, dicha arquitectura se había considerado y descartado para el System/360 . ^{[ 29 ]} Una forma de aumentar la velocidad del sistema es mantener los datos lo más cerca posible del procesador. En la pila del B5000, esto se logró asignando las dos posiciones superiores de la pila a dos registros, A y B. La mayoría de las operaciones se realizan en esas dos posiciones superiores de la pila. En máquinas más rápidas posteriores al B5000, se puede mantener una mayor parte de la pila en registros o caché cerca del procesador.

De este modo, los diseñadores de los sucesores actuales de los sistemas B5000 pueden optimizar su código con la técnica más reciente, y los programadores no tienen que modificarlo para que funcione más rápido; ni siquiera necesitan recompilarlo, protegiendo así la inversión en software. Se sabe que algunos programas han funcionado durante años tras numerosas actualizaciones de procesador. Esta aceleración es limitada en las máquinas basadas en registros.

Otro argumento a favor de la velocidad, promovido por los diseñadores de RISC, era que el procesador era considerablemente más rápido si todo estaba integrado en un solo chip. Esto era cierto en la década de 1970, cuando arquitecturas más complejas como la B5000 requerían demasiados transistores para caber en un solo chip. Sin embargo, hoy en día esto no es así, y todos los procesadores sucesores de la B5000 ahora caben en un solo chip, al igual que las técnicas de soporte de rendimiento como las cachés y las tuberías de instrucciones.

De hecho, la línea de sucesores de la serie A del B5000 incluía el primer ordenador central de un solo chip, el Micro-A de finales de la década de 1980. Este chip "computadora central" (denominado SCAMP, por Single-Chip A-series Mainframe Processor) se montaba en una placa de circuito impreso enchufable basada en Intel.

Aquí hay un ejemplo de cómo los programas se asignan a la estructura de la pila.

comenzar — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Este es el nivel léxico 2 (el nivel cero está reservado para el sistema operativo y el nivel 1 para los segmentos de código). — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — En el nivel 2 colocamos variables globales para nuestro programa. entero i , j , k ; real f , g ; matriz a [0:9]; procedimiento p ( real p1 , p2 ); valor p1 ; — p1 se pasa por valor, p2 se pasa implícitamente por referencia. inicio — — — — — — — — — — — — — — — — — — — Este bloque está en el nivel léxico 3 — — — — — — — — — — — — — — — — — — real r1 , r2 ; r2 := p1 * 5 ; p2 := r2 ; — Esto establece g al valor de r2 p1 := r2 ; — Esto establece p1 a r2 , pero no f — Dado que esto sobrescribe el valor original de f en p1, podría ser un — error de codificación. Por lo tanto, algunos de los sucesores de ALGOL insisten en que — Los parámetros de valor deberían ser de solo lectura, pero la mayoría no lo son. Si r2 > 10 , entonces comienza. — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Una variable declarada aquí hace que este nivel léxico sea 4. — — — — — — — — — — — — — — — — — — — — — — — — — — — — entero n ; — La declaración de una variable convierte esto en un bloque, que invocará alguna — código de construcción de pila. Normalmente no declararás variables aquí, en el que — este sería un enunciado compuesto, no un bloque. ... <== La pila de muestra se está ejecutando en algún lugar aquí. fin ; fin ; ..... p ( f , g ); fin .

Cada marco de pila corresponde a un nivel léxico en el entorno de ejecución actual. Como se puede observar, el nivel léxico se refiere al anidamiento textual estático de un programa, no al anidamiento dinámico de llamadas. Las reglas de visibilidad de ALGOL, un lenguaje diseñado para compiladores de una sola pasada, implican que solo las variables declaradas antes de la posición actual son visibles en esa parte del código, de ahí la necesidad de declaraciones anticipadas. Todas las variables declaradas en los bloques que las contienen son visibles. Otro caso es que variables con el mismo nombre pueden declararse en bloques internos, lo que oculta efectivamente las variables externas, que se vuelven inaccesibles.

El anidamiento léxico es estático, independiente del anidamiento de ejecución con recursión, etc., por lo que es muy raro encontrar un procedimiento anidado a más de cinco niveles de profundidad, y podría argumentarse que tales programas estarían mal estructurados. Las máquinas B5000 permiten un anidamiento de hasta 32 niveles. Esto podría causar dificultades en algunos sistemas que generan código fuente Algol como salida (adaptado para resolver algún problema específico) si el método de generación anida frecuentemente un procedimiento dentro de otro.

Los procedimientos pueden invocarse de cuatro maneras: normal, llamada, proceso y ejecución.

La invocación normal invoca un procedimiento de la forma habitual en que cualquier lenguaje invoca una rutina, suspendiendo la rutina que realiza la llamada hasta que el procedimiento invocado finalice.

El mecanismo de llamada invoca un procedimiento como una corrutina. Las corrutinas son tareas asociadas que se establecen como entidades síncronas que operan en su propia pila al mismo nivel léxico que el proceso que las inicia. El control se transfiere explícitamente entre el proceso que inicia y la corrutina mediante una instrucción CONTINUE .

El mecanismo de procesos invoca un procedimiento como una tarea asíncrona con una pila independiente que se configura a partir del nivel léxico del procedimiento procesado. Al ser una tarea asíncrona, no hay control sobre el momento exacto en que se transferirá el control entre las tareas, a diferencia de las corrutinas. El procedimiento procesado aún tiene acceso al entorno que lo contiene, lo que constituye un mecanismo de comunicación entre procesos (IPC) muy eficiente. Dado que dos o más tareas ahora tienen acceso a variables comunes, deben sincronizarse para evitar condiciones de carrera, lo cual se gestiona mediante el tipo de datos EVENT, donde los procesos pueden ESPERAR a uno o más eventos hasta que sean provocados por otro proceso cooperativo. Los EVENT también permiten la sincronización por exclusión mutua a través de las funciones PROCURE y LIBERATE. Si por alguna razón la tarea hija termina, la tarea que la invocó puede continuar; sin embargo, si el proceso padre termina, todos los procesos hijos se terminan automáticamente. En una máquina con más de un procesador, los procesos pueden ejecutarse simultáneamente. Este mecanismo EVENT es un habilitador básico para el multiprocesamiento, además de la multitarea.

Datos de la etiqueta D: pareja de direcciones, comentarios registro

| 0 | n | (4, 1) El entero n (declarado al entrar en un bloque, no en un procedimiento) |-----------------------| | D[4]==>3 | MSCW | (4, 0) La palabra de control de la pila de marcas que contiene el enlace a D[3]. |=======================| | 0 | r2 | (3, 5) El r2 real |-----------------------| | 0 | r1 | (3, 4) El r1 real |-----------------------| | 1 | p2 | (3, 3) Una referencia SIRW a g en (2,6) |-----------------------| | 0 | p1 | (3, 2) El parámetro p1 a partir del valor de f |-----------------------| | 3 | RCW | (3, 1) Palabra de control de retorno |-----------------------| | D[3]==>3 | MSCW | (3, 0) La palabra de control de la pila de marcas que contiene el enlace a D[2]. |=======================| | 1 | a | (2, 7) El arreglo a ======>[bloque de memoria de diez palabras] |-----------------------| | 0 | g | (2, 6) La g real |-----------------------| | 0 | f | (2, 5) La f real |-----------------------| | 0 | k | (2, 4) El entero k |-----------------------| | 0 | j | (2, 3) El entero j |-----------------------| | 0 | i | (2, 2) El entero i |-----------------------| | 3 | RCW | (2, 1) Palabra de control de retorno |-----------------------| | D[2]==>3 | MSCW | (2, 0) La palabra de control de la pila de marcas que contiene el enlace al marco de pila anterior. |=======================| — Fondo de la pila

 MATRIZ A [0:99]

 MATRIZ EBCDIC EA [0] = A [*];

 MATRIZ HEXAGONAL HA [0] = A [*];

 MATRIZ ASCII AA[0] = A[*];

 MATRIZ EBCDIC MY_EA [0:99]

Una ventaja de la estructura de pila es que, si un programa falla, se genera un volcado de pila y resulta muy sencillo para el programador averiguar el estado exacto del programa en ejecución. Compárese esto con los volcados de memoria y los paquetes de intercambio de otros sistemas.

Otra característica de la estructura de pila es que los programas son implícitamente recursivos. No se esperaba que FORTRAN admitiera recursión, y quizás uno de los obstáculos para comprender cómo se implementaría ALGOL fue precisamente cómo implementarla. En el B5000, esto no supuso un problema; de hecho, se enfrentaron al problema inverso: cómo evitar que los programas fueran recursivos. Al final, no se molestaron en ello. El compilador Burroughs FORTRAN permitía llamadas recursivas (al igual que todos los demás compiladores FORTRAN), pero a diferencia de muchos otros ordenadores, en un sistema basado en pila, los retornos de dichas llamadas también se ejecutaban correctamente. Esto podía tener efectos extraños, como en un sistema para la manipulación formal de expresiones matemáticas cuyas subrutinas centrales se invocaban repetidamente entre sí sin devolver ningún valor: ¡los trabajos grandes terminaban por desbordamiento de pila!

Así, Burroughs FORTRAN tenía una mejor comprobación de errores que otras implementaciones contemporáneas de FORTRAN. Por ejemplo, para subrutinas y funciones, comprobaba que se invocaran con el número correcto de parámetros, como es habitual en los compiladores de estilo ALGOL. En otros ordenadores, tales discrepancias eran causas comunes de fallos. Lo mismo ocurría con la comprobación de límites de matrices: programas que se habían utilizado durante años en otros sistemas fallaban con frecuencia al ejecutarse en un sistema Burroughs. De hecho, Burroughs se hizo conocido por sus compiladores superiores y su implementación de lenguajes, incluido el Simula orientado a objetos (un superconjunto de ALGOL), e Iverson , el diseñador de APL , declaró que la implementación de APL de Burroughs era la mejor que había visto. John McCarthy , el diseñador del lenguaje LISP , no estaba de acuerdo, ya que LISP se basaba en código modificable ; no le gustaba el código no modificable del B5000 , pero la mayoría de las implementaciones de LISP se ejecutaban en un entorno interpretado de todos modos.

El almacenamiento necesario para los múltiples procesos provenía del conjunto de memoria del sistema según se requería. No era necesario realizar SYSGEN en los sistemas Burroughs, como ocurría con los sistemas de la competencia, para preconfigurar las particiones de memoria en las que se ejecutarían las tareas.

Los programas en los procesadores B5000, B5500 y B5700 se componen de sílabas de 12 bits , cuatro por palabra. La arquitectura tiene dos modos: Modo Palabra y Modo Carácter, cada uno con un repertorio de sílabas independiente. Un procesador puede estar en estado de control o en estado normal, y ciertas sílabas solo son admisibles en estado de control. La arquitectura no permite el direccionamiento directo de registros o memoria; todas las referencias se realizan a través de la Tabla de Referencia de Programa de 1024 palabras, el segmento de código actual, las ubicaciones marcadas en la pila o los registros A y B que contienen las dos ubicaciones superiores de la pila. Burroughs numera los bits de una sílaba del 0 (bit alto) al 11 (bit bajo).

Los programas se componen de sílabas de 8 bits , que pueden ser Llamada por Nombre, Llamada por Valor o formar un operador, que puede tener de una a doce sílabas de longitud. Hay menos de 200 operadores , todos los cuales caben en sílabas de 8 bits. Muchos de estos operadores son polimórficos dependiendo del tipo de datos sobre los que se actúa, según lo especificado por la etiqueta. Si ignoramos los potentes operadores de escaneo, transferencia y edición de cadenas, el conjunto básico es de solo unos 120 operadores. Si eliminamos los operadores reservados para el sistema operativo, como MVST y HALT, el conjunto de operadores comúnmente utilizados por los programas de nivel de usuario es inferior a 100. Las sílabas de Llamada por Nombre y Llamada por Valor contienen pares de direcciones ; las sílabas de Operador no usan direcciones o usan palabras de control y descriptores en la pila.