Burroughs Large Systems Group produjo una familia de grandes mainframes de 48 bits utilizando conjuntos de instrucciones de máquina apilada con sílabas densas . [NB 1] La primera máquina de la familia fue la B5000 en 1961, que estaba optimizada para compilar extremadamente bien programas ALGOL 60 , utilizando compiladores de un solo paso. El B5000 evolucionó hasta convertirse en el B5500 (disco en lugar de tambor) y el B5700 (hasta cuatro sistemas ejecutándose como un clúster). Los importantes rediseños posteriores incluyen la línea B6500/B6700 y sus sucesores, así como la línea B8500 separada.
En la década de 1970, Burroughs Corporation estaba organizada en tres divisiones con arquitecturas de línea 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 una computadora para lenguajes de programación particulares. "Burroughs Large Systems" se refería a todas estas líneas de productos de sistemas grandes juntas, en contraste con los sistemas medianos optimizados para COBOL (B2000, B3000 y B4000) o los sistemas pequeños de arquitectura flexible (B1000).
Fundada en la década de 1880, Burroughs era la empresa informática en funcionamiento continuo más antigua ( 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 equipo informático todavía se limitaba a máquinas contables electromecánicas como la Sensimatic . No tenía nada que competir con sus rivales tradicionales IBM y NCR , que habían comenzado a producir computadoras a mayor escala, o con la recientemente fundada Univac . En 1956, compraron ElectroData Corporation y cambiaron el nombre de su diseño a 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ó el B6500 (y los posteriores B6700 y B7700). Las computadoras que usaban esa arquitectura estaban [ cita necesaria ] todavía 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 patentado , Unisys también utiliza 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, en 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 partir de 1961 por un equipo bajo el liderazgo de Robert (Bob) Barton . Tenía una arquitectura inusual. Ha sido catalogada 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 y 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 para la B5700, la línea B5000 influyó mucho en el diseño de la B6500, y Burroughs transfirió el Programa de Control Maestro ( MCP ) a esa máquina.
El B5000 era inusual en ese momento porque la arquitectura y el conjunto de instrucciones se diseñaron teniendo en cuenta las necesidades del software. Esta fue una gran desviación del diseño de sistemas informáticos de la época, donde se diseñaba un procesador y su conjunto de instrucciones y luego se entregaba a la gente del software.
Los B5000, B5500 y B5700 en Modo Word tienen dos modos de direccionamiento diferentes, dependiendo de si está ejecutando un programa principal (SALF apagado) o una subrutina (SALF encendido). Para un programa principal, el campo T de una sílaba de llamada de operando o llamada de descriptor es relativa a la tabla de referencia del programa (PRT). Para las subrutinas, el tipo de direccionamiento depende de los tres bits superiores de T y del Mark Stack FlipFlop (MSFF), como se muestra en B5x00 Direccionamiento relativo.
El B5000 fue diseñado para soportar exclusivamente lenguajes de alto nivel. Esto fue en un momento en que dichos lenguajes apenas estaban ganando importancia con FORTRAN y luego COBOL . Algunos consideraban que FORTRAN y COBOL eran lenguajes más débiles cuando se trataba de 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 poderosas instrucciones de procesamiento de cadenas. La famosa conferencia del Premio Turing de Hoare versó sobre este tema.
Así, el B5000 se basó 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 estuvo involucrado periféricamente 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 el mismo poder 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 fue muy rápido; esto impresionó al científico holandés Edsger Dijkstra cuando presentó un programa para compilarlo 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 . 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 usarse, 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 compiló tan rápido como los lectores de 1000 tarjetas/minuto podían leer el código. El programa estuvo listo para usarse tan pronto como las tarjetas pasaron por el lector.
El B6500 [7] (entrega en 1969 [8] [9] ) y el B7500 [ cita necesaria ] fueron las primeras computadoras de la única línea de sistemas Burroughs que sobrevivieron hasta el día de hoy. Si bien se inspiraron en el B5000, tenían una arquitectura totalmente nueva. Entre las diferencias más importantes estaban
Entre otros clientes de B6700 y B7700 se encontraban las cinco universidades de Nueva Zelanda en 1971. [11]
La línea B8500 [1] [2] deriva de la D825, [12] una computadora militar que se inspiró en la 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 magnética de película delgada . La arquitectura empleaba una palabra, una pila y descriptores de 48 bits como el B5500, pero no se anunciaba como compatible con versiones posteriores. [1] Nunca se pudo lograr que el B8500 funcionara de manera confiable y el proyecto se canceló después de 1970, sin haberse entregado nunca un sistema completo. [2]
El concepto central de memoria virtual apareció en los diseños del Ferranti Atlas y del Rice Institute Computer , y los conceptos centrales de descriptores y arquitectura etiquetada aparecieron en el diseño del Rice Institute Computer [13] a finales de los años cincuenta. Sin embargo, aunque esos diseños tuvieron una influencia directa en Burroughs, las arquitecturas de las B5000, B6500 y B8500 eran muy diferentes de las de las Atlas y Rice; también son muy diferentes entre sí.
El primero de los grandes sistemas de Burroughs fue el B5000. Diseñada en 1961, era una computadora de segunda generación que utilizaba lógica de transistores discretos y memoria de núcleo magnético , seguida por la B5500 y la B5700. Las primeras máquinas que reemplazaron la arquitectura B5000 fueron la B6500 y la B7500. Las máquinas sucesoras de B6500 y 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 B6500, B7500, B6700, B7700, B6800, B7800, B5900, [NB 4] B7900 y finalmente la serie Burroughs A. Después de una fusión en la que Burroughs adquirió Sperry Corporation y cambió su nombre a Unisys , la empresa continuó desarrollando nuevas máquinas basadas en el MCP CMOS ASIC . Estas máquinas fueron la 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 dividieron en dos ubicaciones principales, en el condado de Orange, California , y las afueras de Filadelfia . La planta de sistemas grandes inicial, 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 sede en una planta en Mission Viejo, California , pero que en ocasiones 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 , se encargaban de 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 manejaron la conmutación de procesos y las 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, y procesadores de mantenimiento más altamente funcionales. Cuando los modelos Bxx00 fueron reemplazados por los modelos de la Serie A, las diferencias se mantuvieron pero ya no fueron fácilmente identificables 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 admitir ALGOL, esto fue solo un punto de partida. Otros lenguajes orientados a los negocios, como COBOL, también contaban con un buen soporte, sobre todo por los potentes operadores de cadenas que se incluyeron para el desarrollo de compiladores rápidos.
El ALGOL utilizado en el B5000 es un subconjunto ALGOL extendido. Incluye potentes instrucciones de manipulación de cadenas, pero excluye ciertas construcciones ALGOL, en particular parámetros formales no especificados. Un mecanismo DEFINE tiene un propósito similar al #defines que se encuentra 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 manejar fallas del programa.
El nivel de usuario de ALGOL no incluye muchas de las construcciones inseguras que necesita el sistema operativo y otro software del sistema. Dos niveles de extensiones de lenguaje proporcionan 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 extendido llamado ESPOL (Lenguaje orientado a la programación de sistemas ejecutivos). Este fue reemplazado a mediados y finales de los años 70 por un lenguaje llamado NEWP . Aunque NEWP probablemente solo significaba "Nuevo lenguaje de programación", hay leyendas que rodean el nombre. Una historia común (quizás apócrifa) dentro de Burroughs en ese momento sugirió 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ó el lenguaje "NEWP" después de que le preguntaran, una vez más, "¿ya tiene nombre?": respondiendo "nyoooop", adoptó eso como un nombre. NEWP también era un subconjunto de extensión 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 tipo de marcado de bloques proporciona un mecanismo de protección de varios niveles.
Los programas NEWP que contienen construcciones 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 esencialmente privilegios de root, pueden no poder hacer esto dependiendo de la configuración elegida por el sitio). Si bien NEWP se puede usar para escribir programas generales y tiene una serie de características diseñadas para grandes proyectos de software , no es compatible con todo lo que hace ALGOL.
NEWP tiene una serie de instalaciones para permitir proyectos de software a gran escala, como el sistema operativo, incluidas 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 fácil acceso a los datos de forma global dentro del módulo. Las interfaces permiten que un módulo importe y exporte funciones y datos. Los supermódulos permiten agrupar módulos.
En la implementación original, el sistema utilizaba un procesador de comunicaciones de datos (DCP) especializado adjunto 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 la memoria, esencialmente paquetes en los términos actuales, y el MCS realizaba el procesamiento de esos mensajes en el lado B6500. En los primeros años, el DCP tenía un ensamblador (Dacoma), un programa de aplicación llamado DCPProgen escrito en B6500 ALGOL. Posteriormente, el compilador NDL (lenguaje de definición de red) generó el código DCP y el NDF (archivo de definición de red). Finalmente, una nueva actualización resultó en el desarrollo del lenguaje y compilador NDLII que se utilizaron junto con los DCP modelo 4 y 5. Había una función ALGOL para cada tipo de instrucción DCP, y si llamaba a esa función, los bits de instrucción DCP correspondientes se emitirían 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 declaración en lenguaje ensamblador. Esencialmente, ALGOL actuó como el pase macro de un ensamblador macro. El primer paso fue el compilador ALGOL; el segundo paso fue ejecutar el programa resultante (en el B6500) que luego emitiría 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 basada en LAN para el sistema mainframe. Los dispositivos remotos y los servidores/mainframes remotos se conectaron 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 externo no requirió ningún cambio en el software MCS (Sistema de control de mensajes (que se analiza a continuación)) existente.
En la entrada, los mensajes se pasaban desde el DCP a través de un bus interno a la pila de procesos DCP de MCP Datacom Control (DCC) relevante. Se inició un proceso DCC para cada DCP configurado en el sistema. La pila de procesos DCP luego garantizaría que el mensaje entrante estuviera en cola para su entrega al MCS identificado para manejar el tráfico desde el dispositivo de origen particular y devolverí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 manejar diferentes tipos de hardware de puerta de enlace, ya sea cualquiera de los 5 estilos de DCP o las combinaciones ICP o ICP/CP2000.
Además 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, en días posteriores, JAVA). Un MCS puede considerarse un programa de middleware y está escrito en DCALGOL (ALGOL de comunicaciones de datos). Como se indicó anteriormente, el MCS recibió mensajes de colas mantenidas por Datacom Control Stack (DCC) y reenvió estos mensajes a la aplicación/función adecuada para su procesamiento. Uno de los MCS originales fue CANDE (Comando Y Edición), que se desarrolló como 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 la serie IBM 360. sistemas. Otro MCS llamado COMS se introdujo alrededor de 1984 y se desarrolló como un sistema de control de procesamiento de transacciones de alto rendimiento. Existieron entornos de procesamiento de transacciones predecesores que incluían GEMCOS (Sistema de control de mensajes generalizado) y una subsidiaria australiana de Burroughs desarrolló MCS llamado TPMCS (Transaction Processing MCS). Los MCS de procesamiento de transacciones respaldaron la entrega de datos de aplicaciones a entornos de producción en línea y la devolución de respuestas a usuarios/dispositivos/sistemas remotos.
Los MCS son elementos de software que vale la pena destacar: controlan las sesiones de los usuarios y permiten realizar un seguimiento del estado del usuario sin tener que ejecutar procesos por usuario, ya que muchos usuarios pueden compartir una única pila de MCS. El equilibrio de carga también se puede lograr a nivel de MCS. Por ejemplo, decir que desea manejar 30 usuarios por pila, en cuyo caso si tiene de 31 a 60 usuarios, tendrá dos pilas, de 61 a 90 usuarios, tres pilas, etc. Esto le da a las máquinas B5000 una gran ventaja de rendimiento en un servidor ya que no necesita iniciar otro proceso de usuario y así crear una nueva pila cada vez que un usuario se conecta al sistema. Por lo tanto, puede brindar servicios eficientes 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 EE. UU. que utilizaba el procesador de comunicaciones distribuidas CP2000 como host de protocolo. Dos o tres años más tarde, la implementación de TCP/IP se reescribió para que estuviera basada en host/servidor con importantes mejoras de rendimiento y 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 (ALGOL de gestión de datos). DMALGOL es una extensión de ALGOL para compilar el software de base de datos DMSII a partir de archivos de descripción de bases de datos creados por el compilador DASDL (lenguaje de definición de estructura y acceso a datos). 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 a 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 en tiempo de compilación. Esto permite una adaptación mucho más allá de lo que se puede hacer con instalaciones de preprocesamiento que carecen de bucles.
DMALGOL se utiliza para proporcionar rutinas de acceso personalizadas para bases de datos DMSII . Después de definir una base de datos utilizando 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 hay necesidad de 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 del código y el tiempo de ejecución. Se volvió mucho menos utilizado 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 aplicaciones de ALGOL para admitir el acceso a bases de datos desde programas de aplicación se llama BDMSALGOL e incluye verbos como "FIND", "LOCK", "STORE", "GET" y "PUT" para el acceso a bases de datos y manipulación de registros. Además, también se implementaron los verbos "BEGINTRANSACTION" y "ENDTRANSACTION" para resolver la situación de punto muerto cuando varios procesos accedían y actualizaban 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 era una preocupación menor, la mayoría de las construcciones de preprocesamiento estuvieron disponibles en el nivel de usuario de ALGOL. Sólo las construcciones no seguras y el procesamiento directo del archivo de descripción de la base de datos permanecen restringidos a DMALGOL.
En muchos de los primeros sistemas y lenguajes, a los programadores se les solía decir que no hicieran sus rutinas demasiado pequeñas. Las llamadas y devoluciones de procedimientos eran costosas porque era necesario realizar una serie de operaciones para mantener la pila. El B5000 fue diseñado como una máquina apilada: todos los datos del programa, excepto las matrices (que incluyen cadenas y objetos), se guardaban en la pila. Esto significó que las operaciones de pila se optimizaron para lograr eficiencia. Como máquina orientada a pila, no hay registros direccionables por el programador.
La multitarea también es muy eficiente en las líneas B5000 y B6500. Hay instrucciones específicas para realizar cambios de proceso:
Cada pila y la tabla de referencia del programa (PRT) [NB 5] asociada representa un proceso (tarea o subproceso) y las tareas pueden bloquearse en espera de solicitudes de recursos (lo que incluye esperar a que se ejecute un procesador si la tarea se ha interrumpido debido a una acción preventiva). multitarea). Los programas de usuario no pueden emitir una IP1, [NB 5] IP2 [NB 5] o MVST, [NB 6] y sólo hay un lugar en el sistema operativo donde esto se hace.
Entonces, un cambio de proceso procede de algo como esto: un proceso solicita un recurso que no está disponible de inmediato, tal vez una 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 ingresa y ejecuta en la parte superior de la pila de usuarios. Desactiva los temporizadores de procesos del usuario. El proceso actual se coloca en la cola apropiada para el recurso que se solicita, o en la cola lista esperando al procesador si se trata de un cambio de contexto preventivo. El sistema operativo determina el primer proceso en la cola de listos e invoca la instrucción move_stack, que activa el proceso al principio de la cola de listos.
Se consideró que el rendimiento de la pila era lento en comparación con las arquitecturas basadas en registros; por ejemplo, dicha arquitectura se había considerado y rechazado para 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 a la B5000, se puede mantener una mayor parte de la pila en registros o caché cerca del procesador.
Por lo tanto, los diseñadores de los actuales sucesores de los sistemas B5000 pueden optimizar con cualquier técnica más reciente, y los programadores no tienen que ajustar su código para que se ejecute más rápido; ni siquiera necesitan recompilarlo, protegiendo así la inversión en software. Se sabe que algunos programas se ejecutan durante años con muchas actualizaciones de procesador. Esta velocidad está limitada en las máquinas basadas en registros. [ cita necesaria ]
Otro punto a favor de la velocidad promovido por los diseñadores de RISC fue que la velocidad del procesador es considerablemente más rápida si todo está en un solo chip. Fue un punto válido en la década de 1970, cuando arquitecturas más complejas como el B5000 requerían demasiados transistores para caber en un solo chip. Sin embargo, este no es el caso hoy en día y cada máquina sucesora del B5000 ahora cabe en un solo chip, así como en técnicas de soporte de rendimiento, como cachés y canales de instrucciones.
De hecho, la línea 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 de "mainframe" (llamado SCAMP por el procesador de mainframe de un solo chip de la serie A) se encontraba en una placa de PC enchufable basada en Intel.
A continuación se muestra 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 segmentos de código). — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — En el nivel 2 colocamos variables globales para nuestro programa. entero i , j , k ; reales f , g ; matriz a [0:9]; procedimiento p ( real p1 , p2 ); valor p1 ; - p1 pasado por valor, p2 implícitamente pasado por referencia. comenzar — — — — — — — — — — — — — — — — — — — Este bloque está en el nivel léxico 3. — — — — — — — — — — — — — — — — — — reales r1 , r2 ;
r2 := p1 * 5 ; p2 := r2 ; — Esto establece g al 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. si r2 > 10 entonces comienza — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Una variable declarada aquí hace que este nivel léxico sea 4 — — — — — — — — — — — — — — — — — — — — — — — — — — — — número entero norte ;
— La declaración de una variable la convierte en un bloque, que invocará algunos — código de construcción de pila. Normalmente no declararás variables aquí, en las que - En caso de que esto sería una declaración compuesta, no un bloque. ... <== la pila de muestra se está ejecutando en algún lugar aquí. fin ; fin ; ..... pag ( f , gramo ); 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 el anidamiento textual estático de un programa, no el anidamiento dinámico de llamadas. Las reglas de visibilidad de ALGOL, un lenguaje diseñado para compiladores de un solo paso, 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 directas. Todas las variables declaradas en bloques adjuntos son visibles. Otro caso es que se pueden declarar variables con el mismo nombre en bloques internos y estos ocultan efectivamente las variables externas que se vuelven inaccesibles.
El anidamiento léxico es estático, no tiene relación con el anidamiento de ejecución con recursividad, 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 anidar hasta 32 niveles. Esto podría causar dificultades para algunos sistemas que generaron la fuente Algol como salida (adaptada para resolver algún problema especial) si el método de generación frecuentemente anidaba un procedimiento dentro de un procedimiento.
Los procedimientos se pueden invocar de cuatro formas: normal, llamada, proceso y ejecución.
La invocación normal invoca un procedimiento de la misma manera que cualquier lenguaje invoca una rutina, suspendiendo la rutina que llama hasta que regrese el procedimiento invocado.
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 al mismo nivel léxico que el proceso inicial. El control se transfiere explícitamente entre el proceso iniciador y la corrutina mediante una instrucción CONTINUAR .
El mecanismo del 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 exactamente cuándo se pasará el control entre las tareas, a diferencia de las corrutinas. El procedimiento procesado todavía tiene acceso al entorno circundante y este es un mecanismo IPC (Comunicación entre procesos) muy eficiente. Dado que dos o más tareas ahora tienen acceso a variables comunes, las tareas deben sincronizarse para evitar condiciones de carrera, que son manejadas por el tipo de datos EVENTO, donde los procesos pueden ESPERAR en uno o más eventos hasta que sea causado por otro proceso cooperativo. . Los EVENTOS 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 realiza la llamada 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 de EVENTOS es un habilitador básico para el multiprocesamiento además de la multitarea.
Se ejecuta el último tipo de invocación . Esto ejecuta un procedimiento como una tarea independiente que puede continuar después de que finalice el proceso de origen. Por esta razón, el proceso hijo no puede acceder a las variables en el entorno del padre y todos los parámetros pasados al procedimiento invocado deben ser llamados por valor.
Por lo tanto, Burroughs Extended ALGOL tenía algunas de las características de multiprocesamiento y sincronización de lenguajes posteriores como Ada . Hizo uso del soporte para procesos asincrónicos integrado en el hardware.
Una última posibilidad es que en NEWP se pueda declarar un procedimiento INLINE , es decir, cuando el compilador ve una referencia a él, el código para el procedimiento se genera en línea para ahorrar la sobrecarga de una llamada a procedimiento; Esto se hace mejor con fragmentos pequeños de código. Las funciones en línea son similares a las macros parametrizadas como C #defines, excepto que no tienes los problemas con los parámetros que sí puedes tener con las macros.
En el programa de ejemplo sólo se utilizan llamadas normales, por lo que toda la información estará en una única pila. Para llamadas asincrónicas, se inicia una pila separada para cada proceso asincrónico para que los procesos compartan datos pero se ejecuten de forma asincrónica.
Una optimización del hardware de la pila es la provisión de registros D (o "visualización"). Estos son registros que apuntan al inicio de cada marco de pila llamado. Estos registros se actualizan automáticamente a medida que se ingresan y salen de los procedimientos y no son accesibles mediante ningún software que no sea el MCP. Hay 32 registros D, que es lo que limita las operaciones a 32 niveles de anidamiento léxico.
Considere 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 tanto, está representada por el par de direcciones (2, 6). Si no tenemos registros D, tenemos que mirar la palabra de control en la base del marco D[5], que apunta al marco que contiene el entorno D[4]. Luego miramos 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 hasta el nivel léxico requerido. Este no es el mismo camino que el camino de regreso a través de los procedimientos que se han convocado 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 los registros D, el registro D[2] apunta a la base del entorno léxico de nivel 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 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 los registros D, el acceso a entidades en entornos externos y globales es igual de eficiente como acceso a variables locales.
D Datos de etiqueta: pareja de direcciones, comentariosregistro
| 0 | norte | (4, 1) El número entero n (declarado al entrar en un bloque, no en 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 | un | (2, 7) La matriz a ======>[bloque de memoria de diez palabras]|----------------------|| 0 | gramo | (2, 6) La verdadera g |----------------------|| 0 | f | (2, 5) La verdadera f |----------------------|| 0 | k | (2, 4) El número entero k |----------------------|| 0 | j | (2, 3) El número entero j |----------------------|| 0 | yo | (2, 2) El número 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 enlace al marco de pila anterior.|========================| — Apilar abajo
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 todavía tienen acceso al entorno D[2] como está implícito 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 apunte al entorno D[2] de otro proceso encima de su propia pila de procesos. En un instante, todo el espacio de direcciones del entorno de ejecución del código cambia, lo que hace que el entorno D[2] en la propia pila de procesos no sea direccionable directamente y, en su lugar, 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 cruzada de este tipo, el código de llamada y el código llamado podrían incluso originarse a partir de programas escritos en diferentes lenguajes fuente y ser compilados por diferentes compiladores.
Los entornos D[1] y D[0] no ocurren 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 entidades exportadas por el sistema operativo.
En realidad, los marcos de pila ni siquiera tienen que existir en una pila de procesos. Esta característica se usó desde el principio para la optimización de E/S de archivos; el FIB (bloque de información de archivos) se vinculó a los registros de visualización en D[1] durante las operaciones de E/S. A principios de los años noventa, esta capacidad se implementó como una característica del lenguaje como BLOQUES DE ESTRUCTURA y, combinado con tecnología de biblioteca, como BLOQUES DE CONEXIÓN. La capacidad de vincular una estructura de datos en el alcance de la dirección del registro de visualización implementó la orientación a objetos. Por lo tanto, el B6500 en realidad utilizó 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 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 plana de 16 bits, 32 bits o incluso 64 bits. Estas direcciones pueden contener cualquier cosa, por lo que escribir en una dirección incorrecta podría dañar algo. En cambio, el hardware implementó el esquema de direcciones de dos partes. En cada nivel léxico, las variables se colocaron en desplazamientos hacia arriba desde la base de la pila del nivel, ocupando normalmente una palabra; las variables de doble precisión 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 unos pocos miles en casos extremos, ciertamente no un conteo 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 siguiente byte para obtener un campo de direccionamiento de catorce bits. El código que se ejecutaba estaría en algún nivel léxico, digamos seis: esto significaba que sólo los niveles léxicos del cero al seis eran válidos, por lo que sólo se necesitaban tres bits para especificar el nivel léxico deseado. Por lo tanto, la parte de dirección de la operación VALC reservó solo tres bits para ese propósito, y el resto estuvo disponible para hacer referencia a entidades en ese nivel y en niveles inferiores. Un procedimiento profundamente anidado (por lo tanto, en un nivel léxico alto) tendría menos bits disponibles para identificar entidades: para el nivel dieciséis y 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 que el primero. 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 cargaba datos: los códigos de operación para ADD, MULT, etc. no se direccionaban y trabajaban 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 utilizada por otra tarea, porque no tenía forma de desarrollar su dirección. El hardware compararía las compensaciones de un registro D específico con el marco de la pila: los valores no autorizados quedarían atrapados. De manera similar, dentro de una tarea, un descriptor de matriz contenía información sobre los límites de la matriz, por lo que el hardware verificaba cualquier operación de indexación: dicho de otra manera, cada matriz formaba su propio espacio de direcciones. En cualquier caso, el etiquetado de todas las palabras de memoria proporcionó un segundo nivel de protección: una asignación mal dirigida de un valor sólo podría ir a una ubicación que contiene datos, no a una que contenga un puntero o un descriptor de matriz, etc., y ciertamente no a una ubicación que contenga un puntero o un descriptor de matriz, etc. una ubicación que contiene el código de máquina.
Las matrices no se almacenaban contiguas en la memoria con otras variables, a cada una se le concedía su propio espacio de direcciones, que se localizaba a través del descriptor. El mecanismo de acceso consistía en calcular en la pila la variable de índice (que por lo tanto tenía el potencial de rango entero completo, no solo catorce bits) y usarla como desplazamiento en el espacio de direcciones de la matriz, con verificación de límites proporcionada por el hardware. De forma predeterminada, si la longitud de una matriz excede las 1024 palabras, la matriz se segmentará y el índice se convertirá 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í encendido para dimensiones superiores. La verificación del hardware con 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 aritmética entera simple para calcular el desplazamiento donde se encontraría el elemento A[i,j,k] en ese único secuencia. Luego se accedería a la matriz unidimensional equivalente, posiblemente segmentada si es lo suficientemente grande, de la misma manera que a 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; es decir, los índices no fueron verificados individualmente.
Debido a que el almacenamiento de una matriz no estaba limitado en cada lado por el almacenamiento de otros elementos, era fácil para el sistema "cambiar el tamaño" de una matriz, aunque se impedía cambiar el número de dimensiones porque los compiladores requerían que todas las referencias tuvieran la misma cantidad de dimensiones. En el caso de ALGOL, esto permitió el desarrollo de matrices "irregulares", en lugar de las habituales matrices rectangulares fijas (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 declaró como SA[100,0] podría cambiar el tamaño de cada fila para tener exactamente suficientes elementos para contener solo los valores distintos de cero de A a lo largo de esa fila.
Debido a que los arreglos de más de 1024 palabras generalmente se segmentaban pero los arreglos más pequeños no, en un sistema que tenía poca memoria real, aumentar el tamaño declarado de una colección de arreglos de bloc de notas de 1000 a 1050 podría significar que el programa se ejecutaría con mucha menos cantidad. "golpear", ya que sólo se necesitaban 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 de ese segmento, y todos los elementos de un segmento creado se inicializarían a cero. Por lo tanto, esto alentó el no inicializar una matriz a cero al principio, lo que normalmente es 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 podían usarse 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 denominarse datos orientados a caracteres mediante la siguiente declaración de equivalencia:
ARRAY EBCDIC EA [0] = A [*];
o como datos hexadecimales mediante la declaración de equivalencia:
MATRIZ HEXAGONAL HA [0] = A [*];
o como datos ASCII mediante 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
EBCDIC ARRAY MI_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 el número solicitado de caracteres redondeado al siguiente límite de palabra completa.
El descriptor de datos generado en el momento de la compilación indicó el uso del tipo de datos para el que estaba destinada la matriz. Si se realizó una declaración de equivalencia de matriz, se generó un descriptor de copia que indica ese tipo de uso particular, pero que apunta 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 BOOLEAN y pueden usarse como un vector de bits. También se pueden solicitar matrices INTEGER.
La discusión inmediatamente anterior utiliza la implementación de sintaxis ALGOL para describir declaraciones ARRAY, pero la misma funcionalidad es compatible con COBOL y FORTRAN.
Una cosa buena acerca de la estructura de la pila es que si un programa falla, se realiza un volcado de la pila y es muy fácil para un programador descubrir exactamente cuál era el estado de un programa en ejecución. Compare esto con los volcados de memoria y los paquetes de intercambio de otros sistemas.
Otra cosa acerca de la estructura de la pila es que los programas son implícitamente recursivos. No se esperaba que FORTRAN soportara la recursividad y quizás un obstáculo para la comprensión de la gente sobre cómo se iba a implementar ALGOL era cómo implementar la recursividad. En el B5000, esto no fue 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 (al igual que cualquier otro compilador FORTRAN), pero a diferencia de muchas otras computadoras, en un sistema basado en pila los retornos de dichas llamadas también tuvieron éxito. Esto podría tener efectos extraños, como en el caso de un sistema para la manipulación formal de expresiones matemáticas cuyas subrutinas centrales se invocaban repetidamente entre sí sin regresar nunca: ¡los trabajos grandes terminaban por un desbordamiento de la pila!
Por tanto, Burroughs FORTRAN tenía una mejor comprobación de errores que otras implementaciones contemporáneas de FORTRAN. [ cita necesaria ] Por ejemplo, para las subrutinas y funciones verificó que fueran invocadas con la cantidad correcta de parámetros, como es normal para los compiladores de estilo ALGOL. En otras computadoras, estas discrepancias eran causas comunes de fallas. Lo mismo ocurre con la comprobación vinculada a matrices: los programas que se habían utilizado durante años en otros sistemas fallaban vergonzosamente a menudo cuando se ejecutaban 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 por parte de Burroughs era la mejor que había visto. [ cita necesaria ] John McCarthy , el diseñador del lenguaje de LISP no estuvo de acuerdo, dado que LISP se basaba en código modificable [ cita necesaria ] , no le gustaba el código no modificable del B5000 [ cita necesaria ] , pero la mayoría de las implementaciones de LISP se ejecutarían en un modo interpretativo ambiente de todos modos.
El almacenamiento requerido para los múltiples procesos provino del grupo de memoria del sistema según fuera necesario. No había necesidad de realizar SYSGEN en los sistemas Burroughs como ocurre con los sistemas de la competencia para preconfigurar particiones de memoria en las que ejecutar tareas.
El aspecto más definitorio de la B5000 es que es una máquina apiladora como se trató anteriormente. Sin embargo, otras dos características muy importantes de la arquitectura es que está basada en etiquetas y en descriptores.
En el B5000 original, se reservaba un bit de bandera en cada palabra de control o numérica [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 corrompieran las palabras de control en la pila.
Más tarde, cuando se diseñó el B6500, se dio cuenta de que la distinción numérica/palabra de control de 1 bit era una idea poderosa y esto se extendió 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 sólo lectura, por lo que las etiquetas impares indicaban palabras de control que no podían escribirse mediante un programa de nivel de usuario. A las palabras de código se les asignó la etiqueta 3. Aquí hay 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 utilizaban con fines de ingeniería, como un campo de corrección de errores del código Hamming , pero los programadores nunca las vieron.
La encarnació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 etiquetas de cuatro bits se denominaba nivel Gamma.
Las palabras con etiquetas pares son datos del usuario que un programa de usuario puede modificar como estado del 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 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, incluso si la palabra del sistema Es posible que el formato haya cambiado.
Las palabras de la etiqueta 1 representan direcciones de datos en la pila. El IRW normal simplemente almacena un par de direcciones de datos en la pila actual. El SIRW hace referencia a datos en cualquier pila al incluir un número de pila en la dirección. Entre otras cosas, los SIRW se utilizan para proporcionar direccionamiento entre pilas de procesos discretos, como los generados en respuesta a las declaraciones 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 al procedimiento. Cuando los operadores de hardware golpean una PCW, se ingresa el procedimiento. El operador ENTR ingresa explícitamente un procedimiento (rutina sin devolución de valor). Las funciones (rutinas de devolución de valores) las ingresan implícitamente operadores como la llamada de valor (VALC). Las rutinas globales se almacenan en el entorno D[2] como SIRW que apuntan a una PCW almacenada 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 todos los procesos que comparten este código pueden hacer referencia a él. Por 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, TOSCW.
La figura de la izquierda muestra cómo la arquitectura Burroughs Large System era fundamentalmente una arquitectura hardware para programación orientada a objetos , algo que todavía no existe en las arquitecturas convencionales.
Hay tres conjuntos de instrucciones distintos para los grandes sistemas de Burroughs. Los tres se basan en sílabas cortas que encajan uniformemente en las palabras.
Los programas en 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, 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 están permitidas en el estado de control. La arquitectura no permite direccionar registros o almacenamiento directamente; todas las referencias se realizan a través de la tabla de referencia del programa 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 del 0 (bit alto) al 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 actúa según lo indicado por la etiqueta. Si ignoramos los potentes operadores de escaneo, transferencia y edición de cadenas, el conjunto básico es sólo de 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 Name Call y Value Call contienen parejas de direcciones; las sílabas del operador no usan direcciones o usan palabras de control y descriptores en la pila.
La línea B5000 también fue pionera en tener dos procesadores conectados entre sí en un bus de alta velocidad como maestro y esclavo. En las líneas B6000, B7000 y B8000 los procesadores eran simétricos. La línea B7000 podría tener hasta ocho procesadores, siempre que al menos uno fuera un módulo de E/S. RDLK (Leer con LocK) es una forma de sincronización de muy bajo nivel entre procesadores. RDLK opera en un solo ciclo. El mecanismo de nivel superior generalmente empleado por los programas de usuario es el tipo de datos EVENTO . El tipo de datos EVENTO tenía cierta sobrecarga del sistema. Para evitar esta sobrecarga, se puede utilizar una técnica de bloqueo especial llamada cerraduras Dahm (que lleva el nombre de un gurú del software de Burroughs, Dave Dahm). Los bloqueos Dahm utilizaron la declaración de lenguaje READLOCK ALGOL que generó un operador RDLK a nivel de código.
Los operadores notables son:
HEYU : envía una interrupción a otro procesador.
RDLK : operador de semáforo de bajo nivel: carga el registro A con la ubicación de memoria proporcionada por el registro A y coloca el valor en el registro B en esa ubicación de memoria en un único ciclo ininterrumpible. El compilador Algol produjo código para invocar este operador a través de una función especial que permitía una operación de "intercambio" en datos de una sola palabra sin un valor temporal explícito. x:=RDLK(x,y);
WHOI : identificación del procesador
IDLE : inactivo hasta que se recibe una interrupción
En raras ocasiones, dos procesadores podían enviarse simultáneamente entre sí un comando 'HEYU', lo que provocaba un bloqueo conocido como 'un abrazo mortal '.
La influencia directa del B5000 se puede ver en la gama actual de mainframes Unisys ClearPath, que son descendientes directos del B6500, que fue influenciado por el B5000, y todavía tienen el sistema operativo MCP después de 40 años de desarrollo constante. Esta arquitectura ahora se llama emode (para modo de emulación) ya que la arquitectura B6500 se implementó en máquinas construidas con procesadores Intel Xeon que ejecutan el conjunto de instrucciones x86 como conjunto de instrucciones nativo, con código ejecutándose en esos procesadores emulando el conjunto de instrucciones B5000. En esas máquinas, también iba a haber un nmode ( modo nativo ), pero se eliminó [ cita requerida ] , por lo que es posible que a menudo escuche que se hace referencia a las máquinas sucesoras del B6500 como "máquinas emode".
Las máquinas B5000 fueron programadas exclusivamente en lenguajes de alto nivel; no hay ensamblador.
La arquitectura de pila del B5000 inspiró a Chuck Moore , el diseñador del lenguaje de programación Forth , quien encontró el B5500 mientras estaba en el MIT. En Forth - The Early Years, Moore describió la influencia y señaló que DUP, DROP y SWAP de Forth provienen de las instrucciones B5500 correspondientes (DUPL, DLET, EXCH).
Las máquinas B5000 con su arquitectura basada en pila y memoria etiquetada también influyeron mucho en la serie de mainframes y supercomputadoras soviéticas Elbrus . Las dos primeras generaciones de la serie presentaban memoria etiquetada y CPU basadas en pila que se programaban únicamente en lenguajes de alto nivel. Existía para ellos una especie de lenguaje ensamblador , llamado El-76, pero era más o menos una modificación de ALGOL 68 y soportaba programación estructurada y procedimientos de primera clase. Sin embargo, las generaciones posteriores de la serie cambiaron de esta arquitectura a CPU VLIW tipo EPIC .
Los diseñadores de Hewlett-Packard del sistema empresarial HP 3000 habían utilizado un B5500 y quedaron muy impresionados por su hardware y software; Su objetivo era construir una minicomputadora de 16 bits con software similar. Varias otras divisiones de HP crearon máquinas apiladas con minicomputadoras o microprocesadores similares. El trabajo de Bob Barton sobre notación polaca inversa (RPN) también llegó a las calculadoras HP a partir de la 9100A, y en particular a la HP-35 y calculadoras posteriores.
Los sistemas NonStop diseñados por Tandem Computers a finales de los años 1970 y principios de los 1980 también eran máquinas de pila de 16 bits, influenciadas por el B5000 indirectamente a través de la conexión HP 3000, como lo hicieron varios de los primeros ingenieros de Tandem anteriormente en HP. Alrededor de 1990, estos sistemas migraron a la arquitectura MIPS RISC pero continuaron admitiendo la ejecución de archivos binarios de máquinas de pila mediante traducción de código objeto o emulación directa. En algún momento después del año 2000, estos sistemas migraron a la arquitectura Itanium y continuaron ejecutando los binarios de las máquinas de pila heredadas.
Bob Barton también fue muy influyente en Alan Kay . Kay también quedó impresionado por la arquitectura etiquetada basada en datos del B5000 y esto influyó en su pensamiento en sus desarrollos en programación orientada a objetos y Smalltalk . [ cita necesaria ]
Otra faceta de la arquitectura B5000 fue que era una arquitectura segura que se ejecuta directamente en el hardware. Esta técnica tiene descendientes en las máquinas virtuales de hoy [ cita necesaria ] en sus intentos de proporcionar entornos seguros. Uno de estos productos notables es Java JVM, que proporciona un entorno limitado seguro en el que se ejecutan las aplicaciones.
El valor de la vinculación de arquitectura de hardware que existía antes de emode se conservaría sustancialmente en las máquinas basadas en x86 en la medida en que MCP fuera el único programa de control, pero el soporte proporcionado por esas máquinas sigue siendo inferior al proporcionado en la versión anterior. máquinas donde el conjunto de instrucciones B6500 es el conjunto de instrucciones nativo. Una arquitectura de procesador Intel poco conocida que en realidad precedió a las implementaciones de 32 bits del conjunto de instrucciones x86, el Intel iAPX 432 , habría proporcionado una base física equivalente, ya que también era esencialmente una arquitectura orientada a objetos.