El Burroughs Large Systems Group produjo una familia de grandes mainframes de 48 bits que utilizaban conjuntos de instrucciones de máquina de pila con sílabas densas . [NB 1] La primera máquina de la familia fue la B5000 en 1961, que estaba optimizada para compilar programas ALGOL 60 extremadamente bien, utilizando compiladores de una sola pasada. La B5000 evolucionó hasta convertirse en la B5500 (disco en lugar de tambor) y la B5700 (hasta cuatro sistemas funcionando como un clúster). Los rediseños importantes posteriores incluyen la línea B6500/B6700 y sus sucesores, así como la línea B8500 independiente.
En la década de 1970, Burroughs Corporation se organizó en tres divisiones con arquitecturas de líneas de productos muy diferentes para sistemas informáticos empresariales de gama alta, media y básica. La línea de productos de cada división surgió de un concepto diferente sobre cómo optimizar el conjunto de instrucciones de un ordenador para lenguajes de programación concretos. El término "Grandes sistemas Burroughs" hacía referencia a todas estas líneas de productos de grandes sistemas en conjunto, en contraste con los sistemas medianos optimizados para COBOL (B2000, B3000 y B4000) o los pequeños sistemas de arquitectura flexible (B1000).
Fundada en la década de 1880, Burroughs era la empresa informática más antigua que operaba de forma continua ( Elliott Brothers se fundó antes que Burroughs, pero no fabricó dispositivos informáticos en el siglo XIX). A finales de la década de 1950, su equipamiento informático todavía se limitaba a máquinas de contabilidad electromecánicas como la Sensimatic . No tenía nada con lo que competir con sus rivales tradicionales IBM y NCR , que habían empezado a producir ordenadores de mayor escala, o con la recién fundada Univac . En 1956, compraron ElectroData Corporation y rebautizaron su diseño como B205.
La primera máquina desarrollada internamente por Burroughs, la B5000, fue diseñada en 1961 y Burroughs buscó abordar su entrada tardía en el mercado con la estrategia de un diseño completamente diferente basado en las ideas informáticas más avanzadas disponibles en ese momento. Si bien la arquitectura B5000 está muerta, inspiró la B6500 (y las posteriores B6700 y B7700). Las computadoras que usaban esa arquitectura todavía estaban [ cita requerida ] en producción como los servidores Unisys ClearPath Libra que ejecutan una versión evolucionada pero compatible del sistema operativo MCP introducido por primera vez con el B6700. La tercera y más grande línea, la B8500, [1] [2] no tuvo éxito comercial. Además de un diseño de procesador CMOS propietario, Unisys también usa procesadores Intel Xeon y ejecuta sistemas operativos MCP , Microsoft Windows y Linux en sus servidores Libra; el uso de chips personalizados se eliminó gradualmente y, para 2018, los servidores Libra habían sido estrictamente productos básicos de Intel durante algunos años.
El primer miembro de la primera serie, el B5000, [3] fue diseñado a principios de 1961 por un equipo bajo el liderazgo de Robert (Bob) Barton . Tenía una arquitectura inusual. Ha sido catalogado por el científico informático John Mashey como una de las arquitecturas que más admira. "Siempre pensé que era uno de los ejemplos más innovadores de diseño combinado de hardware/software que he visto, y muy adelantado a su tiempo". [4] El B5000 fue sucedido por el B5500, [5] que usaba discos en lugar de almacenamiento en tambor, y el B5700, que permitía agrupar múltiples CPU alrededor de un disco compartido. Si bien no hubo un sucesor del B5700, la línea B5000 influyó en gran medida en el diseño del B6500, y Burroughs trasladó el Programa de Control Maestro ( MCP ) a esa máquina.
El B5000 era una característica inusual en su época, ya que su arquitectura y conjunto de instrucciones se diseñaron teniendo en cuenta las necesidades del software. Esto supuso un gran cambio con respecto al diseño de sistemas informáticos de la época, en el que se diseñaba un procesador y su conjunto de instrucciones y luego se entregaba a los diseñadores de software.
Los B5000, B5500 y B5700 en modo Word tienen dos modos de direccionamiento diferentes, dependiendo de si están ejecutando un programa principal (SALF desactivado) o una subrutina (SALF activado). Para un programa principal, el campo T de una sílaba de llamada de operando o de llamada de descriptor es relativo a la tabla de referencia de programa (PRT). Para las subrutinas, el tipo de direccionamiento depende de los tres bits superiores de T y del flip-flop de pila de marcas (MSFF), como se muestra en Direccionamiento relativo de B5x00.
El B5000 fue diseñado para soportar exclusivamente lenguajes de alto nivel. Esto fue en un momento en que dichos lenguajes estaban empezando a cobrar importancia con FORTRAN y luego COBOL . FORTRAN y COBOL eran considerados lenguajes más débiles por algunos, en lo que se refiere a técnicas de software modernas, por lo que se adoptó un lenguaje más nuevo, en su mayoría no probado, ALGOL-60 . El dialecto ALGOL elegido para el B5000 fue Elliott ALGOL , diseñado e implementado por primera vez por CAR Hoare en un Elliott 503. Esta era 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 del Premio Turing de Hoare fue sobre este tema.
Así, el 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ó de forma periférica en el diseño del 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 se dieron cuenta del 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 que lo compilaran en la planta B5000 de Pasadena. Su baraja de cartas se compiló casi de inmediato y de inmediato 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 . Las primeras computadoras no tenían suficiente memoria para almacenar el código fuente, por lo que los compiladores (e incluso los ensambladores) generalmente necesitaban 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 podían leer el código fuente de las tarjetas perforadas , y tenían los lectores de tarjetas más rápidos de la industria.
El potente compilador COBOL de Burroughs también era un compilador de una sola pasada e igualmente rápido. Un programa COBOL de 4000 tarjetas se compilaba tan rápido como los lectores de 1000 tarjetas por minuto podían leer el código. El programa estaba listo para usarse tan pronto como las tarjetas pasaban por el lector.
El B6500 [7] (entregado en 1969 [8] [9] ) y el B7500 [ cita requerida ] fueron los primeros ordenadores de la única línea de sistemas Burroughs que sobrevivieron hasta nuestros días. Si bien estaban inspirados en el B5000, tenían una arquitectura totalmente nueva. Entre las diferencias más importantes se encontraban
Entre otros clientes del B6700 y el B7700 se encontraban las cinco universidades de Nueva Zelanda en 1971. [11]
La línea B8500 [1] [2] deriva del D825, [12] un ordenador militar que se inspiró en el B5000.
El B8500 fue diseñado en la década de 1960 como un intento de fusionar los diseños B5500 y D825. El sistema utilizaba circuitos integrados monolíticos con memoria de película fina magnética . La arquitectura empleaba una palabra de 48 bits, una pila y descriptores como el B5500, pero no se publicitaba como compatible con versiones anteriores. [1] El B8500 nunca pudo funcionar de manera confiable y el proyecto se canceló después de 1970, sin haber entregado nunca un sistema completo. [2]
El concepto central de memoria virtual apareció en los diseños del Atlas Ferranti y el Rice Institute Computer , y los conceptos centrales de descriptores y arquitectura etiquetada aparecieron en el diseño del Rice Institute Computer [13] a fines de la década de 1950. Sin embargo, incluso si esos diseños tuvieron una influencia directa en Burroughs, las arquitecturas del B5000, B6500 y B8500 eran muy diferentes de las del Atlas y la máquina Rice; también son muy diferentes entre sí.
El primero de los grandes sistemas de Burroughs fue el B5000. Diseñado en 1961, fue un ordenador de segunda generación que utilizaba lógica de transistores discretos y memoria de núcleo magnético , seguido por el B5500 y el B5700. Las primeras máquinas que reemplazaron la arquitectura B5000 fueron el B6500 y el B7500. Las máquinas sucesoras del B6500 y el B7500 siguieron las tendencias de desarrollo de hardware para volver a implementar las arquitecturas en nueva lógica durante los siguientes 25 años, con el B6500, el B7500, el B6700, el B7700, el B6800, el B7800, el B5900, el [NB 4] B7900 y finalmente la serie A de Burroughs. Después de una fusión en la que Burroughs adquirió Sperry Corporation y cambió su nombre a Unisys , la compañía continuó desarrollando nuevas máquinas basadas en el MCP CMOS ASIC . Estas máquinas fueron las Libra 100 a la Libra 500, y la Libra 590 se anunció en 2005. Las Libra posteriores, incluida la 590, también incorporan procesadores Intel Xeon y pueden ejecutar la arquitectura de sistemas grandes de Burroughs en emulación, así como en los procesadores MCP CMOS. No está claro si Unisys continuará con el desarrollo de nuevos ASIC MCP CMOS.
El diseño, desarrollo y fabricación de hardware y software se dividió entre dos ubicaciones principales, en el condado de Orange, California , y las afueras de Filadelfia . La planta inicial de sistemas grandes, que desarrolló el B5000 y el B5500, estaba ubicada en Pasadena, California, pero se trasladó a City of Industry, California , donde desarrolló el B6500. La ubicación del condado de Orange, que tenía su base en una planta en Mission Viejo, California , pero a veces incluía instalaciones en las cercanas Irvine y Lake Forest , era responsable de la línea B6x00 más pequeña, mientras que las operaciones de la costa este, con sede en Tredyffrin, Pensilvania , manejaban la línea B7x00 más grande. Todas las máquinas de ambas líneas eran totalmente compatibles con objetos, lo que significa que un programa compilado en una podía ejecutarse en otra. Los modelos más nuevos y más grandes tenían instrucciones que no eran compatibles con los modelos más antiguos y más lentos, pero el hardware, cuando encontraba una instrucción no reconocida, invocaba una función del sistema operativo que la interpretaba. Otras diferencias incluyen cómo se manejaban el cambio de proceso y la E/S, y la funcionalidad de mantenimiento y arranque en frío. Los sistemas más grandes incluían programación de procesos de hardware y módulos de entrada/salida más capaces, así como procesadores de mantenimiento más funcionales. Cuando los modelos Bxx00 fueron reemplazados por los modelos de la Serie A, se mantuvieron las diferencias, pero ya no se podían identificar fácilmente por el número de modelo.
Los grandes sistemas de Burroughs implementan arquitecturas de pila derivadas de ALGOL . El B5000 fue el primer sistema basado en pila.
Si bien B5000 fue diseñado específicamente para soportar ALGOL, esto fue solo un punto de partida. Otros lenguajes orientados a los negocios, como COBOL, también fueron bien soportados, en particular por los poderosos operadores de cadena que se incluyeron para el desarrollo de compiladores rápidos.
El ALGOL utilizado en el B5000 es un subconjunto extendido de ALGOL. Incluye instrucciones de manipulación de cadenas potentes, pero excluye ciertas construcciones de ALGOL, en particular los parámetros formales no especificados. Un mecanismo DEFINE cumple una función similar a las #defines que se encuentran 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 procesos y los bloques ON FAULT permiten gestionar los fallos del programa.
El nivel de usuario de ALGOL no incluye muchas de las construcciones inseguras que necesitan el sistema operativo y otro software del sistema. Dos niveles de extensiones del lenguaje proporcionan las construcciones adicionales: ESPOL y NEWP para escribir el MCP y software estrechamente relacionado, y DCALGOL y DMALGOL para proporcionar extensiones más específicas para tipos específicos de software del sistema.
Originalmente, el sistema operativo B5000 MCP se escribió en una extensión de ALGOL extendida llamada ESPOL (lenguaje orientado a la programación de sistemas ejecutivos). Este fue reemplazado a mediados y fines de los años 70 por un lenguaje llamado NEWP . Aunque NEWP probablemente solo significaba "Nuevo lenguaje de programación", hay leyendas alrededor del 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 ". Otra historia es que alrededor de 1976, John McClintock de Burroughs (el ingeniero de software que desarrolló NEWP) nombró al lenguaje "NEWP" después de que le preguntaran, una vez más, "¿ya tiene un nombre?": respondiendo "nyoooop", adoptó ese como nombre. NEWP también era una extensión de subconjunto de ALGOL, pero era más seguro que ESPOL y eliminaba algunas complejidades poco utilizadas de ALGOL. De hecho, el compilador NEWP rechaza todas las construcciones inseguras a menos que un bloque esté marcado específicamente para permitir esas instrucciones. Este marcado de bloques proporciona un mecanismo de protección de varios niveles.
Los programas NEWP que contienen estructuras inseguras inicialmente no son ejecutables. El administrador de seguridad de un sistema puede "bendecir" dichos programas y hacerlos ejecutables, pero los usuarios normales no pueden hacerlo. (Incluso los "usuarios privilegiados", que normalmente tienen privilegios de root, pueden no poder hacerlo según la configuración elegida por el sitio). Si bien NEWP se puede usar para escribir programas generales y tiene varias características diseñadas para proyectos de software grandes, no admite todo lo que hace ALGOL.
NEWP cuenta con una serie de funciones que permiten proyectos de software a gran escala, como el sistema operativo, que incluyen interfaces con nombre (funciones y datos), grupos de interfaces, módulos y supermódulos. Los módulos agrupan datos y funciones, lo que permite un acceso fácil a los datos como globales dentro del módulo. Las interfaces permiten que un módulo importe y exporte funciones y datos. Los supermódulos permiten agrupar los módulos.
En la implementación original, el sistema utilizaba un procesador de comunicaciones de datos (DCP) especializado para manejar la entrada y salida de mensajes desde/hacia dispositivos remotos. Se trataba de una minicomputadora de 24 bits con una arquitectura de registro convencional y capacidad de E/S de hardware para manejar miles de terminales remotas. El DCP y el B6500 se comunicaban mediante mensajes en memoria, esencialmente paquetes en términos actuales, y el MCS realizaba el procesamiento de esos mensajes en el lado del B6500. En los primeros años, el DCP tenía un ensamblador (Dacoma), un programa de aplicación llamado DCPProgen escrito en ALGOL del B6500. Más tarde, el compilador NDL (lenguaje de definición de red) generaba el código DCP y el NDF (archivo de definición de red). Finalmente, una actualización posterior dio como resultado el desarrollo del lenguaje y compilador NDLII que se usaban junto con los DCP modelo 4 y 5. Había una función ALGOL para cada tipo de instrucción DCP y, si se llamaba a esa función, se emitirían los bits de instrucción DCP correspondientes a la salida. Un programa DCP era un programa ALGOL que no comprendía nada más que una larga lista de llamadas a estas funciones, una para cada instrucción en lenguaje ensamblador. En esencia, ALGOL actuaba como el paso macro de un ensamblador macro. El primer paso era el compilador ALGOL; el segundo paso era ejecutar el programa resultante (en el B6500) que luego emitiría el binario para el DCP.
A principios de los años 80, la tecnología DCP fue reemplazada por el ICP (procesador de comunicaciones integrado) que proporcionaba conectividad basada en LAN para el sistema mainframe. Los dispositivos remotos y los servidores/mainframes remotos se conectaban a la red a través de dispositivos independientes llamados CP2000. Los CP2000 se diseñaron para proporcionar soporte de nodos de red en una red distribuida en la que los nodos se conectaban mediante la tecnología de red BNAV2 (Burroughs Network Architecture Version 2). BNAV2 era un equivalente funcional de Burroughs del producto IBM SNA y admitía la interoperación con entornos IBM en los modos de transporte PUT2 y PUT5. El cambio en el hardware de comunicaciones de datos externos no requirió ningún cambio en el software MCS (Message Control System (discutido más adelante)) existente.
En la entrada, los mensajes se pasaban desde el DCP a través de un bus interno a la pila de procesos DCP del Control de comunicación de datos MCP (DCC) correspondiente. Se iniciaba un proceso DCC para cada DCP configurado en el sistema. La pila de procesos DCP se aseguraba entonces de que el mensaje entrante se pusiera en cola para su entrega al MCS identificado para gestionar el tráfico desde el dispositivo de origen en particular y devolvía cualquier respuesta al DCP para su entrega al dispositivo de destino. Desde una perspectiva de procesamiento, no se requirieron cambios en el software MCS para gestionar diferentes tipos de hardware de puerta de enlace, ya sea cualquiera de los 5 estilos de DCP o las combinaciones ICP o ICP/CP2000.
Aparte de ser un servicio de entrega de mensajes, un MCS es 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, incluidos COBOL, FORTRAN y, más tarde, JAVA). Un MCS puede considerarse un programa de middleware y está escrito en DCALGOL (Data Communications ALGOL). Como se indicó anteriormente, el MCS recibía mensajes de colas mantenidas por la pila de control de comunicaciones de datos (DCC) y enviaba estos mensajes a la aplicación/función adecuada para su procesamiento. Uno de los MCS originales fue CANDE (Command AND Edit), que se desarrolló como el entorno de desarrollo de programas en línea. La Universidad de Otago en Nueva Zelanda desarrolló un entorno de desarrollo de programas delgado equivalente a CANDE al que llamaron SCREAM/6700 al mismo tiempo que IBM ofrecía un servicio de desarrollo de programas/tiempo compartido remoto conocido como CALL/360 que se ejecutaba en sistemas de la serie IBM 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. Hubo entornos de procesamiento de transacciones predecesores que incluían GEMCOS (sistema generalizado de control de mensajes), y una subsidiaria australiana de Burroughs desarrolló un MCS llamado TPMCS (sistema de procesamiento de transacciones). Los MCS de procesamiento de transacciones respaldaban la entrega de datos de aplicaciones a entornos de producción en línea y la devolución de respuestas a usuarios, dispositivos y sistemas remotos.
Los MCS son elementos de software que vale la pena destacar: controlan las sesiones de usuario y permiten realizar un seguimiento del estado del usuario sin tener que ejecutar procesos por usuario, ya que una sola pila MCS puede ser compartida por muchos usuarios. El equilibrio de carga también se puede lograr a nivel de MCS. Por ejemplo, si se quiere gestionar 30 usuarios por pila, en cuyo caso, si se tienen entre 31 y 60 usuarios, se tienen dos pilas; si se tienen entre 61 y 90 usuarios, se tienen tres pilas, etc. Esto proporciona a las máquinas B5000 una gran ventaja de rendimiento en un servidor, ya que no es necesario iniciar otro proceso de usuario y, por lo tanto, crear una nueva pila cada vez que un usuario se conecta al sistema. De este modo, se puede dar servicio de manera eficiente a los usuarios (ya sea que requieran estado o no) con MCS. Los MCS también proporcionan la columna vertebral del procesamiento de transacciones a gran escala.
Alrededor de 1988 se desarrolló una implementación de TCP/IP principalmente para un cliente del gobierno de los EE. UU. que utilizaba el procesador de comunicaciones distribuidas CP2000 como host del protocolo. Dos o tres años después, se reescribió la implementación de TCP/IP para que estuviera basada en host/servidor con mejoras significativas en el rendimiento y la funcionalidad. En el mismo período general se realizó una implementación de las pilas de protocolos OSI, principalmente en el CP2000, pero se implementó una gran infraestructura de soporte en el sistema principal. Se implementaron todas las aplicaciones definidas por el estándar OSI, incluido 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 descripciones de bases de datos para generar código DMALGOL adaptado a las tablas e índices especificados. Los administradores nunca necesitan escribir DMALGOL ellos mismos. Los programas normales de nivel de usuario obtienen acceso a la base de datos mediante el uso de código escrito en lenguajes de aplicación, principalmente ALGOL y COBOL, ampliado con instrucciones de base de datos y directivas de procesamiento de transacciones. La característica más notable de DMALGOL son sus mecanismos de preprocesamiento para generar código para manejar 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 que va mucho más allá de lo que se puede hacer con las funciones de preprocesamiento que carecen de bucles.
DMALGOL se utiliza para proporcionar rutinas de acceso personalizadas para bases de datos DMSII . Una vez definida una base de datos mediante el lenguaje de definición de estructura y acceso a datos (DASDL), el preprocesador traduce el esquema en rutinas de acceso DMALGOL personalizadas y luego lo compila. Esto significa que, a diferencia de otras implementaciones de DBMS, a menudo no es necesario un código if/then/else específico de la base de datos en tiempo de ejecución. En la década de 1970, esta "adaptación" se utilizó ampliamente para reducir la huella de código y el tiempo de ejecución. Se volvió mucho menos utilizada en años posteriores, en parte porque el ajuste fino de bajo nivel para la memoria y la velocidad se volvió menos crítico, 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, también se implementaron los verbos "BEGINTRANSACTION" y "ENDTRANSACTION" para resolver la situación de bloqueo 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, cuando el tamaño del código del compilador dejó de ser una preocupación, la mayoría de las construcciones de preprocesamiento se pusieron a disposición en el nivel de usuario de ALGOL. Solo las construcciones no seguras y el procesamiento directo del archivo de descripción de la base de datos siguen estando restringidos a DMALGOL.
En muchos de los primeros sistemas y lenguajes, a los programadores se les decía con frecuencia que no hicieran sus rutinas demasiado pequeñas. Las llamadas a procedimientos y los retornos eran costosos, porque se debían realizar varias operaciones para mantener la pila. El B5000 fue diseñado como una máquina de pila: todos los datos del programa, excepto las matrices (que incluyen cadenas y objetos), se guardaban en la pila. Esto significaba que las operaciones de la pila se optimizaban para lograr eficiencia. Como máquina orientada a la pila, no hay registros a los que el programador pueda acceder.
La multitarea también es muy eficiente en las líneas B5000 y B6500. Existen instrucciones específicas para realizar cambios de proceso:
Cada pila y la tabla de referencia de programa (PRT) asociada [NB 5] representa un proceso (tarea o subproceso) y las tareas pueden quedar bloqueadas mientras esperan solicitudes de recursos (lo que incluye esperar a que se ejecute un procesador si la tarea se ha interrumpido debido a una multitarea preventiva). Los programas de usuario no pueden emitir un IP1, [NB 5] IP2 [NB 5] o MVST, [NB 6] y solo hay un lugar en el sistema operativo donde esto se hace.
Un cambio de proceso se produce de la siguiente manera: un proceso solicita un recurso que no está disponible de inmediato, tal vez la lectura de un registro de un archivo de un bloque que no está actualmente en la memoria, o el temporizador del sistema ha activado una interrupción. El código del sistema operativo se introduce y se ejecuta sobre la pila del usuario. Desactiva los temporizadores de procesos del usuario. El proceso actual se coloca en la cola adecuada para el recurso que se solicita, o en la cola de procesos listos que espera al procesador si se trata de un cambio de contexto preventivo. El sistema operativo determina el primer proceso en la cola de procesos listos e invoca la instrucción move_stack, que activa el proceso que encabeza la cola de procesos listos.
Se consideraba que el rendimiento de la pila era lento en comparación con las arquitecturas basadas en registros; por ejemplo, se había considerado y rechazado una arquitectura de este tipo para el System/360 . [24] Una forma de aumentar la velocidad del sistema es mantener los datos lo más cerca posible del procesador. En la pila B5000, esto se hizo 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 esta manera, los diseñadores de los sucesores actuales de los sistemas B5000 pueden optimizarlos con la última tecnología y los programadores no tienen que ajustar su código para que funcione más rápido (ni siquiera necesitan volver a compilarlo), lo que protege la inversión en software. Se sabe que algunos programas funcionan durante años con muchas actualizaciones de procesador. Esta velocidad está limitada en las máquinas basadas en registros. [ cita requerida ]
Otro argumento a favor de la velocidad, tal como lo promovieron los diseñadores de RISC, fue que la velocidad del procesador es considerablemente mayor si todo está en un solo chip. Esto era válido en la década de 1970, cuando las arquitecturas más complejas, como la B5000, requerían que cupieran demasiados transistores en un solo chip. Sin embargo, este no es el caso hoy en día y todas las máquinas sucesoras de la B5000 ahora caben en un solo chip, así como las técnicas de soporte de rendimiento, como las cachés y las secuencias de instrucciones.
De hecho, la línea de la Serie A de sucesores del B5000 incluía el primer mainframe de un solo chip, el Micro-A de finales de los años 1980. Este chip "mainframe" (denominado SCAMP por Single-Chip A-series Mainframe Processor) se encontraba en una placa de PC 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 pasado por valor, p2 pasado implícitamente por referencia. — — — — — — — — — — — — — — — — — — — Este bloque está en el nivel léxico 3 — — — — — — — — — — — — — — — — — — real r1 , r2 ;
r2 := p1 * 5 ; p2 := r2 ; — Esto establece g en el valor de r2 p1 := r2 ; — Esto establece p1 en 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 son de solo lectura, pero la mayoría no lo hacen. 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 a esta en un bloque, que invocará alguna — código de construcción de pila. Normalmente no declarará variables aquí, en las que — En este caso se trataría de una declaración compuesta y no de 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 puede ver, el nivel léxico es la anidación textual estática de un programa, no la anidación de llamadas dinámicas. Las reglas de visibilidad de ALGOL, un lenguaje diseñado para compiladores de una sola pasada, significan que solo las variables declaradas antes de la posición actual son visibles en esa parte del código, de ahí el requisito de declaraciones hacia adelante. Todas las variables declaradas en bloques envolventes son visibles. Otro caso es que las variables del mismo nombre se pueden declarar en bloques internos y estos ocultan efectivamente las variables externas que se vuelven inaccesibles.
La anidación léxica es estática, no está relacionada con la anidación 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 se podría argumentar que dichos programas estarían mal estructurados. Las máquinas B5000 permiten la anidación de hasta 32 niveles. Esto podría causar dificultades para algunos sistemas que generaron la fuente de Algol como salida (adaptada para resolver algún problema especial) si el método de generación anidaba con frecuencia un procedimiento dentro de otro.
Los procedimientos se pueden invocar de cuatro maneras: normal, llamada, proceso y ejecución.
La invocación normal invoca un procedimiento de la misma manera en que cualquier lenguaje invoca una rutina, suspendiendo la rutina que llama hasta que el procedimiento invocado regrese.
El mecanismo de llamada invoca un procedimiento como una corrutina. Las corrutinas son tareas asociadas establecidas como entidades sincrónicas que operan en su propia pila en el mismo nivel léxico que el proceso iniciador. El control se transfiere explícitamente entre el proceso iniciador y la corrutina por medio de una instrucción CONTINUE .
El mecanismo de proceso invoca un procedimiento como una tarea asincrónica con una pila separada configurada a partir del nivel léxico del procedimiento procesado. Como tarea asincrónica, no hay control sobre cuándo exactamente se pasará el control entre las tareas, a diferencia de las corrutinas. El procedimiento procesado aún tiene acceso al entorno que lo encierra y este es un mecanismo de comunicación entre procesos (IPC) muy eficiente. Dado que dos o más tareas ahora tienen acceso a variables comunes, las tareas deben sincronizarse para evitar condiciones de carrera, lo que se maneja mediante el tipo de datos EVENT, donde los procesos pueden ESPERAR uno o más eventos hasta que otro proceso cooperante los cause. Los EVENT también permiten la sincronización de exclusión mutua a través de las funciones PROCURE y LIBERATE. Si por alguna razón la tarea secundaria muere, la tarea que la llama puede continuar; sin embargo, si el proceso principal muere, todos los procesos secundarios finalizan 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.
El último tipo de invocación es run . Esto ejecuta un procedimiento como una tarea independiente que puede continuar después de que finalice el proceso original. Por este motivo, el proceso secundario no puede acceder a las variables en el entorno del proceso principal y todos los parámetros que se pasan al procedimiento invocado deben llamarse por valor.
De esta manera, Burroughs Extended ALGOL tenía algunas de las características de multiprocesamiento y sincronización de lenguajes posteriores como Ada . Aprovechaba el soporte para procesos asincrónicos que estaba integrado en el hardware.
Una última posibilidad es que en NEWP un procedimiento se declare INLINE , es decir, cuando el compilador ve una referencia a él , el código del procedimiento se genera en línea para ahorrar la sobrecarga de una llamada a procedimiento; esto se hace mejor para fragmentos pequeños de código. Las funciones en línea son similares a las macros parametrizadas como C #defines, excepto que no se producen los mismos problemas con los parámetros que con las macros.
En el programa de ejemplo, solo se utilizan llamadas normales, por lo que toda la información estará en una sola pila. En el caso de las llamadas asincrónicas, se inicia una pila independiente para cada proceso asincrónico, de modo que los procesos compartan datos pero se ejecuten de forma asincrónica.
Una optimización de hardware de pila es la provisión de registros D (o "de visualización"). Estos son registros que apuntan al inicio de cada marco de pila. Estos registros se actualizan automáticamente a medida que se ingresan y salen de los procedimientos y no son accesibles por ningún software que no sea el MCP. Hay 32 registros D, lo que limita las operaciones a 32 niveles de anidamiento léxico.
Consideremos cómo accederíamos a una variable global de nivel léxico 2 (D[2]) desde el nivel léxico 5 (D[5]). Supongamos que la variable está a 6 palabras de la base del nivel léxico 2. Por lo tanto, está representada por el par de direcciones (2, 6). Si no tenemos D registros, tenemos que buscar la palabra de control en la base del marco D[5], que apunta al marco que contiene el entorno D[4]. Luego buscamos la palabra de control en la base de este entorno para encontrar el entorno D[3] y continuamos de esta manera hasta que hayamos seguido todos los enlaces de regreso al nivel léxico requerido. Esta no es la misma ruta que la ruta de retorno a través de los procedimientos que se han llamado para llegar a este punto. (La arquitectura mantiene tanto la pila de datos como la pila de llamadas en la misma estructura, pero utiliza palabras de control para diferenciarlas).
Como puede ver, esto es bastante ineficiente simplemente para acceder a una variable. Con registros D, el registro D[2] apunta a la base del entorno de nivel léxico 2, y todo lo que necesitamos hacer para generar la dirección de la variable es sumar su desplazamiento desde la base del marco de la pila a la dirección base del marco en el registro D. (Existe un operador de búsqueda de lista enlazada eficiente LLLU, que podría buscar en la pila de la manera anterior, pero el enfoque del registro D seguirá siendo más rápido). Con registros D, el acceso a entidades en entornos externos y globales es tan eficiente como el acceso a variables locales.
Datos de la etiqueta D — Dirección de pareja, Comentariosregistro
| 0 | n | (4, 1) El entero n (declarado al ingresar a un bloque, no a un procedimiento)|-----------------------|| D[4]==>3 | MSCW | (4, 0) La palabra de control de pila de marcas que contiene el enlace a D[3].|========================|| 0 | r2 | (3, 5) El verdadero r2|-----------------------|| 0 | r1 | (3, 4) El verdadero r1|-----------------------|| 1 | p2 | (3, 3) Una referencia SIRW a g en (2,6)|-----------------------|| 0 | p1 | (3, 2) El parámetro p1 del valor de f |-----------------------|| 3 | RCW | (3, 1) Una palabra de control de retorno|-----------------------|| D[3]==>3 | MSCW | (3, 0) La palabra de control de pila de marcas que contiene el enlace a D[2].|========================|| 1 | a | (2, 7) La matriz a ======>[bloque de memoria de diez palabras]|-----------------------|| 0 | g | (2, 6) La verdadera g |-----------------------|| 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) Una palabra de control de retorno|-----------------------|| D[2]==>3 | MSCW | (2, 0) La palabra de control de pila de marcas que contiene el vínculo al marco de pila anterior.|========================| — Parte inferior de la pila
Si hubiéramos invocado el procedimiento p como una corrutina o una instrucción de proceso, el entorno D[3] se habría convertido en una pila separada basada en D[3]. Esto significa que los procesos asincrónicos aún tienen acceso al entorno D[2] como se implica en el código del programa ALGOL. Llevando esto un paso más allá, un programa totalmente diferente podría llamar al código de otro programa, creando un marco de pila D[3] que apunta al entorno D[2] de otro proceso sobre su propia pila de procesos. En un instante, todo el espacio de direcciones del entorno de ejecución del código cambia, haciendo que el entorno D[2] en la propia pila de procesos no sea directamente direccionable y, en cambio, haga que el entorno D[2] en otra pila de procesos sea directamente direccionable. Así es como se implementan las llamadas a la biblioteca. En una llamada entre pilas de este tipo, el código que llama y el código llamado podrían incluso originarse de programas escritos en diferentes lenguajes fuente y ser compilados por diferentes compiladores.
Los entornos D[1] y D[0] no se encuentran en la pila del proceso actual. El entorno D[1] es el diccionario de segmentos de código, que comparten todos los procesos que ejecutan el mismo código. El entorno D[0] representa las entidades exportadas por el sistema operativo.
En realidad, los marcos de pila ni siquiera tienen por qué existir en una pila de procesos. Esta característica se utilizó al principio para la optimización de E/S de archivos; el FIB (bloque de información de archivos) se vinculaba a los registros de visualización en D[1] durante las operaciones de E/S. A principios de los noventa, esta capacidad se implementó como una característica del lenguaje en forma de BLOQUES DE ESTRUCTURA y, combinada con tecnología de bibliotecas, como BLOQUES DE CONEXIÓN. La capacidad de vincular una estructura de datos al ámbito de direcciones del registro de visualización implementó la orientación a objetos. Por lo tanto, el B6500 utilizó realmente una forma de orientación a objetos mucho antes de que se utilizara el término.
En otros sistemas, el compilador podría construir su tabla de símbolos de una manera similar, pero eventualmente los requisitos de almacenamiento se cotejarían y el código de máquina se escribiría para usar direcciones de memoria planas de 16 bits o 32 bits o incluso 64 bits. Estas direcciones podrían contener cualquier cosa, por lo que una escritura en la dirección incorrecta podría dañar cualquier cosa. En cambio, el esquema de direcciones de dos partes fue implementado por el hardware. En cada nivel léxico, las variables se colocaron en desplazamientos hacia arriba desde la base de la pila del nivel, ocupando típicamente una palabra - las variables de precisión doble o complejas ocuparían dos. Las matrices no se almacenaban en esta área, solo se almacenaba un descriptor de una palabra para la matriz. Por lo tanto, en cada nivel léxico, el requisito total de almacenamiento no era grande: docenas, cientos o algunos miles en casos extremos, ciertamente no un recuento que requiriera 32 bits o más. Y de hecho, esto se reflejó en la forma de la instrucción VALC (llamada de valor) que cargaba un operando en la pila. Este código de operación tenía dos bits de longitud y el resto de los bits del byte se concatenaban con el byte siguiente para dar un campo de direccionamiento de catorce bits. El código que se estaba ejecutando estaría en algún nivel léxico, digamos seis: esto significaba que solo eran válidos los niveles léxicos del cero al seis, y por lo tanto solo se necesitaban tres bits para especificar el nivel léxico deseado. La parte de dirección de la operación VALC reservaba así solo tres bits para ese propósito, y el resto estaba disponible para hacer referencia a entidades en ese nivel y niveles inferiores. Un procedimiento profundamente anidado (es decir, en un nivel léxico alto) tendría menos bits disponibles para identificar entidades: para el nivel dieciséis en adelante, se necesitarían cinco bits para especificar la elección de los niveles 0 a 31, dejando así nueve bits para identificar no más de las primeras 512 entidades de cualquier nivel léxico. Esto es mucho más compacto que direccionar entidades por su dirección de memoria literal en un espacio de direccionamiento de 32 bits. Además, solo el código de operación VALC cargó datos: los códigos de operación para ADD, MULT, etc., no realizaron direccionamiento y trabajaron completamente en los elementos superiores de la pila.
Mucho más importante es que este método significaba que muchos errores posibles en sistemas que empleaban direccionamiento plano no podían ocurrir porque eran simplemente indescriptibles incluso a nivel de código de máquina. Una tarea no tenía forma de corromper la memoria en uso por otra tarea, porque no tenía forma de desarrollar su dirección. Los desplazamientos de un registro D especificado serían comprobados por el hardware contra el límite del marco de pila: los valores no autorizados serían atrapados. De manera similar, dentro de una tarea, un descriptor de matriz contenía información sobre los límites de la matriz, y por lo tanto cualquier operación de indexación era comprobada por el hardware: dicho de otra manera, cada matriz formaba su propio espacio de direcciones. En cualquier caso, el etiquetado de todas las palabras de memoria proporcionaba un segundo nivel de protección: una asignación errónea de un valor solo podía ir a una ubicación que contuviera datos, no a una que contuviera un puntero o un descriptor de matriz, etc. y ciertamente no a una ubicación que contuviera código de máquina.
Las matrices no se almacenaban en memoria contiguas a otras variables, sino que se les otorgaba a cada una su propio espacio de direcciones, que se localizaba mediante el descriptor. El mecanismo de acceso consistía en calcular en la pila la variable de índice (que, por lo tanto, tenía todo el potencial de rango entero, no solo catorce bits) y utilizarla como desplazamiento en el espacio de direcciones de la matriz, con la comprobación de límites proporcionada por el hardware. De forma predeterminada, si la longitud de una matriz superaba las 1024 palabras, la matriz se segmentaba y el índice se convertía en un índice de segmento y un desplazamiento en el segmento indexado. Sin embargo, existía la opción de evitar la segmentación especificando la matriz como LONG en la declaración. En el caso de ALGOL, una matriz multidimensional emplearía múltiples niveles de dicho direccionamiento. Para una referencia a A[i,j], el primer índice estaría en una matriz de descriptores, un descriptor para cada una de las filas de A, fila que luego se indexaría con j como para una matriz unidimensional, y así sucesivamente para dimensiones superiores. La comprobación del hardware respecto de los límites conocidos de todos los índices de la matriz evitaría una indexación errónea.
Sin embargo, FORTRAN considera que todas las matrices multidimensionales son equivalentes a una matriz unidimensional del mismo tamaño y, para una matriz multidimensional, se utiliza una aritmética de números enteros simple para calcular el desplazamiento en el que se encontraría el elemento A[i,j,k] en esa secuencia única. La matriz unidimensional equivalente, posiblemente segmentada si es lo suficientemente grande, se accedería entonces de la misma manera que una matriz unidimensional en ALGOL. Aunque se evitaría el acceso fuera de esta matriz, un valor incorrecto para un índice combinado con un valor adecuadamente incorrecto para otro índice podría no dar como resultado una violación de los límites de la matriz de secuencia única; en otras palabras, los índices no se verificaron individualmente.
Como el almacenamiento de una matriz no estaba limitado en cada lado por el almacenamiento de otros elementos, era fácil para el sistema "redimensionar" una matriz, aunque se impedía cambiar el número de dimensiones porque los compiladores exigían que todas las referencias tuvieran el mismo número de dimensiones. En el caso de ALGOL, esto permitió el desarrollo de matrices "irregulares", en lugar de las matrices rectangulares fijas habituales (o de mayor dimensión). Por lo tanto, en dos dimensiones, una matriz irregular tendría filas de diferentes tamaños. Por ejemplo, dada una matriz grande A[100,100] de valores mayoritariamente cero, una representación de matriz dispersa que se declarara como SA[100,0] podría tener cada fila redimensionada para tener exactamente los elementos suficientes para contener solo los valores distintos de cero de A a lo largo de esa fila.
Debido a que las matrices de más de 1024 palabras generalmente se segmentaban, pero las matrices más pequeñas no, en un sistema que carecía de memoria real, aumentar el tamaño declarado de una colección de matrices de scratchpad de 1000 a, digamos, 1050 podría significar que el programa se ejecutaría con mucho menos "desorden", ya que solo se necesitarían en la memoria los segmentos individuales más pequeños en uso. El almacenamiento real para un segmento de matriz se asignaría en tiempo de ejecución solo si se accediera a un elemento en ese segmento, y todos los elementos de un segmento creado se inicializarían a cero. Por lo tanto, esto alentaba el no inicializar una matriz a cero al comienzo, lo que normalmente era una omisión imprudente.
También se admite la equivalencia de matrices. La declaración ARRAY solicitaba la asignación de palabras de datos de 48 bits que se podían usar para almacenar cualquier patrón de bits, pero la práctica operativa general era que cada palabra asignada se consideraba un operando REAL. La declaración de:
MATRIZ A [0:99]
Solicitó la asignación de 100 palabras de espacio de datos de tipo REAL en la memoria. El programador también podría especificar que la memoria podría ser referida como datos orientados a caracteres mediante la siguiente declaración de equivalencia:
MATRIZ EBCDIC EA[0] = A[*];
o como datos hexadecimales a través de la declaración de equivalencia:
MATRIZ HEXAGONAL HA [0] = A [*];
o como datos ASCII a través de la declaración de equivalencia:
MATRIZ ASCII AA[0] = A[*];
También se admite la capacidad de solicitar matrices específicas de tipos de datos sin equivalencia, por ejemplo:
MATRIZ EBCDIC MY_EA [0:99]
Solicitó que el sistema asignara una matriz de 100 caracteres. Dado que la arquitectura se basa en palabras, el espacio real asignado es la cantidad de caracteres solicitada redondeada al siguiente límite de palabras completas.
El descriptor de datos generado en el momento de la compilación indicaba el tipo de uso de datos para el que estaba destinada la matriz. Si se hacía una declaración de equivalencia de matriz, se generaba un descriptor de copia que indicaba ese tipo de uso particular, pero que apuntaba al descriptor original o MOM. De este modo, siempre se garantizaba la indexación de la ubicación correcta en la memoria.
También se admiten matrices BOOLEANAS y se pueden utilizar como vector de bits. También se pueden solicitar matrices INTEGER.
La discusión inmediatamente anterior utiliza la implementación de la sintaxis ALGOL para describir las declaraciones de ARRAY, pero la misma funcionalidad se admite en COBOL y FORTRAN.
Una de las ventajas de la estructura de pila es que, si un programa falla, se realiza un volcado de pila y es muy fácil para un programador averiguar exactamente cuál era el estado de un programa en ejecución. Compárese con los volcados de memoria y los paquetes de intercambio de otros sistemas.
Otra cosa sobre la estructura de pila es que los programas son implícitamente recursivos. No se esperaba que FORTRAN admitiera la recursión y tal vez un obstáculo para que la gente comprendiera cómo se iba a implementar ALGOL era cómo implementar la recursión. En el B5000, esto no era un problema; de hecho, tenían el problema inverso, cómo evitar que los programas fueran recursivos. Al final, no se molestaron. El compilador FORTRAN de Burroughs permitía llamadas recursivas (como cualquier otro compilador FORTRAN), pero a diferencia de muchos otros ordenadores, en un sistema basado en pila los retornos de dichas llamadas también funcionaban. 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 volver nunca: ¡los trabajos grandes terminaban por desbordamiento de pila!
Por lo tanto, Burroughs FORTRAN tenía una mejor comprobación de errores que otras implementaciones contemporáneas de FORTRAN. [ cita requerida ] Por ejemplo, para subrutinas y funciones, verificaba que se invocaran con el número correcto de parámetros, como es normal para los compiladores de estilo ALGOL. En otras computadoras, tales desajustes eran causas comunes de fallas. Lo mismo con la verificación de límites de matriz: los programas que se habían usado durante años en otros sistemas vergonzosamente a menudo fallaban cuando se ejecutaban en un sistema Burroughs. De hecho, Burroughs se hizo conocido por sus compiladores superiores y la implementación de lenguajes, incluido el orientado a objetos Simula (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. [ cita requerida ] John McCarthy , el diseñador del lenguaje de LISP , no estaba de acuerdo, ya que LISP estaba basado en código modificable [ cita requerida ] , no le gustaba el código no modificable del B5000 [ cita requerida ] , pero la mayoría de las implementaciones de LISP se ejecutarían en un entorno interpretativo de todos modos.
El almacenamiento necesario para los múltiples procesos provenía del conjunto de memoria del sistema según fuera necesario. No era necesario ejecutar SYSGEN en los sistemas Burroughs como en los sistemas de la competencia para preconfigurar las particiones de memoria en las que se ejecutaban las tareas.
El aspecto más característico del B5000 es que se trata de una máquina de pila, como se ha explicado anteriormente. Sin embargo, otras dos características muy importantes de la arquitectura son que se basa en etiquetas y descriptores.
En el B5000 original, se reservaba un bit de bandera en cada palabra numérica o de control [NB 7] para identificar la palabra como palabra de control o palabra numérica. Esto era, en parte, un mecanismo de seguridad para evitar que los programas pudieran corromper las palabras de control en la pila.
Más tarde, cuando se diseñó el B6500, se comprendió que la distinción entre palabra de control y número numérico de 1 bit era una idea poderosa y se amplió a tres bits fuera de la palabra de 48 bits en una etiqueta. Los bits de datos son los bits 0 a 47 y la etiqueta está en los bits 48 a 50. El bit 48 era el bit de solo lectura, por lo que las etiquetas impares indicaban palabras de control que no podían ser escritas por un programa de nivel de usuario. A las palabras de código se les asignó la etiqueta 3. A continuación, se incluye una lista de las etiquetas y su función:
Internamente, algunas de las máquinas tenían palabras de 60 bits, y los bits adicionales se usaban para fines de ingeniería, como un campo de corrección de errores del código Hamming , pero los programadores nunca los veían.
La versión actual de estas máquinas, Unisys ClearPath, ha ampliado las etiquetas hasta convertirlas en etiquetas de cuatro bits. El nivel de microcódigo que especificaba las etiquetas de cuatro bits se denominaba nivel Gamma.
Las palabras con etiquetas pares son datos de usuario que pueden ser modificados por un programa de usuario como estado de usuario. Las palabras con etiquetas impares son creadas y utilizadas directamente por el hardware y representan el estado de ejecución de un programa. Dado que estas palabras son creadas y consumidas por instrucciones específicas o por el hardware, el formato exacto de estas palabras puede cambiar entre la implementación del hardware y los programas de usuario no necesitan ser recompilados, ya que el mismo flujo de código producirá los mismos resultados, aunque el formato de las palabras del sistema pueda haber cambiado.
Las palabras de etiqueta 1 representan direcciones de datos en la pila. La IRW normal simplemente almacena una dirección asociada a los datos en la pila actual. La SIRW hace referencia a los datos en cualquier pila incluyendo un número de pila en la dirección. Entre otras cosas, las SIRW se utilizan para proporcionar direccionamiento entre pilas de procesos discretos, como las generadas en respuesta a las instrucciones CALL y PROCESS .
Las palabras de la etiqueta 5 son descriptores, que se describen con más detalle en la siguiente sección. Las palabras de la etiqueta 5 representan direcciones de datos fuera de la pila.
La etiqueta 7 es la palabra de control del programa que describe un punto de entrada de procedimiento. Cuando los operadores de hardware llegan a un PCW, se ingresa al procedimiento. El operador ENTR ingresa explícitamente un procedimiento (rutina que no devuelve valor). Las funciones (rutinas que devuelven valor) son ingresadas implícitamente por operadores como la llamada de valor (VALC). Las rutinas globales se almacenan en el entorno D[2] como SIRW que apuntan a un PCW almacenado en el diccionario de segmentos de código en el entorno D[1]. El entorno D[1] no se almacena en la pila actual porque puede ser referenciado por todos los procesos que comparten este código. Por lo tanto, el código es reentrante y compartido.
La etiqueta 3 representa las palabras de código en sí, que no aparecerán en la pila. La etiqueta 3 también se utiliza para las palabras de control de pila MSCW, RCW y TOSCW.
La figura de la izquierda muestra cómo la arquitectura del Gran Sistema de Burroughs era fundamentalmente una arquitectura de hardware para programación orientada a objetos , algo que todavía no existe en las arquitecturas convencionales.
Existen tres conjuntos de instrucciones distintos para los sistemas grandes de Burroughs. Los tres se basan en sílabas cortas que encajan de manera uniforme en las palabras.
Los programas en un B5000, B5500 y B5700 están compuestos de sílabas de 12 bits , cuatro por palabra. La arquitectura tiene dos modos, el modo de palabra y el modo de carácter, y cada uno tiene un repertorio separado de sílabas. Un procesador puede estar en estado de control o en estado normal, y ciertas sílabas solo se permiten en estado de control. La arquitectura no permite el direccionamiento de registros o almacenamiento directo; todas las referencias se realizan a través de la tabla de referencia de programas de 1024 palabras, el segmento de código actual, las ubicaciones marcadas dentro de 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 de 0 (bit alto) a 11 (bit bajo).
Los programas se componen de sílabas de 8 bits , que pueden ser Name Call, Value Call 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 indicado por la etiqueta. Si ignoramos los poderosos 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 menos de 100. Las sílabas Name Call y Value Call contienen parejas de direcciones; las sílabas Operator no usan direcciones o usan palabras de control y descriptores en la pila.
The B5000 line also were pioneers in having two processors connected together on a high-speed bus as master and slave. In the B6000, B7000 and B8000 lines the processors were symmetric. The B7000 line could have up to eight processors, as long as at least one was an I/O module. RDLK (ReaD with LocK) is a very low-level way of synchronizing between processors. RDLK operates in a single cycle. The higher level mechanism generally employed by user programs is the EVENT data type. The EVENT data type did have some system overhead. To avoid this overhead, a special locking technique called Dahm locks (named after a Burroughs software guru, Dave Dahm) can be used. Dahm locks used the READLOCK ALGOL language statement which generated a RDLK operator at the code level.
Notable operators are:
HEYU — send an interrupt to another processor
RDLK — Low-level semaphore operator: Load the A register with the memory location given by the A register and place the value in the B register at that memory location in a single uninterruptible cycle. The Algol compiler produced code to invoke this operator via a special function that enabled a "swap" operation on single-word data without an explicit temporary value. x:=RDLK(x,y);
WHOI — Processor identification
IDLE — Idle until an interrupt is received
Two processors could infrequently simultaneously send each other a 'HEYU' command resulting in a lockup known as 'a deadly embrace'.
The direct influence of the B5000 can be seen in the current Unisys ClearPath range of mainframes which are the direct descendants of the B6500, which was influenced by the B5000, and still have the MCP operating system after 40 years of consistent development. This architecture is now called emode (for emulation mode) since the B6500 architecture has been implemented on machines built from Intel Xeon processors running the x86 instruction set as the native instruction set, with code running on those processors emulating the B5000 instruction set. In those machines, there was also going to be an nmode (native mode), but this was dropped[citation needed], so you may often hear the B6500 successor machines being referred to as "emode machines".
B5000 machines were programmed exclusively in high-level languages; there is no assembler.
The B5000 stack architecture inspired Chuck Moore, the designer of the programming language Forth, who encountered the B5500 while at MIT. In Forth - The Early Years, Moore described the influence, noting that Forth's DUP, DROP and SWAP came from the corresponding B5500 instructions (DUPL, DLET, EXCH).
B5000 machines with their stack-based architecture and tagged memory also heavily influenced the Soviet Elbrus series of mainframes and supercomputers. The first two generations of the series featured tagged memory and stack-based CPUs that were programmed only in high-level languages. There existed a kind of an assembly language for them, called El-76, but it was more or less a modification of ALGOL 68 and supported structured programming and first-class procedures. Later generations of the series, though, switched away from this architecture to the EPIC-like VLIW CPUs.
The Hewlett-Packard designers of the HP 3000 business system had used a B5500 and were greatly impressed by its hardware and software; they aimed to build a 16-bit minicomputer with similar software. Several other HP divisions created similar minicomputer or microprocessor stack machines. Bob Barton's work on reverse Polish notation (RPN) also found its way into HP calculators beginning with the 9100A, and notably the HP-35 and subsequent calculators.
The NonStop systems designed by Tandem Computers in the late 1970s and early 1980s were also 16-bit stack machines, influenced by the B5000 indirectly through the HP 3000 connection, as several of the early Tandem engineers were formerly with HP. Around 1990, these systems migrated to MIPS RISC architecture but continued to support execution of stack machine binaries by object code translation or direct emulation. Sometime after 2000, these systems migrated to Itanium architecture and continued to run the legacy stack machine binaries.
Bob Barton was also very influential on Alan Kay. Kay was also impressed by the data-driven tagged architecture of the B5000 and this influenced his thinking in his developments in object-oriented programming and Smalltalk.[citation needed]
Another facet of the B5000 architecture was that it was a secure architecture that runs directly on hardware. This technique has descendants in the virtual machines of today[citation needed] in their attempts to provide secure environments. One notable such product is the Java JVM which provides a secure sandbox in which applications run.
The value of the hardware-architecture binding that existed before emode would be substantially preserved in the x86-based machines to the extent that MCP was the one and only control program, but the support provided by those machines is still inferior to that provided on the machines where the B6500 instruction set is the native instruction set. A little-known Intel processor architecture that actually preceded 32-bit implementations of the x86 instruction set, the Intel iAPX 432, would have provided an equivalent physical basis, as it too was essentially an object-oriented architecture.