De Wikipedia, la enciclopedia libre
  (Redirigido desde B5000 )
Saltar a navegación Saltar a búsqueda

El Gran Grupo de Sistemas Burroughs produjo una familia de grandes 48 bits ordenadores centrales que utilizan máquinas pila de conjuntos de instrucciones con densos sílabas . [NB 1] La primera máquina de la familia fue la B5000 en 1961. Se optimizó para compilar muy bien los programas ALGOL 60 , utilizando compiladores de una sola pasada. Se convirtió en el B5500. Los rediseños importantes 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 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 creció a partir 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 refiere a todas estas líneas de productos de sistemas grandes juntas, en contraste con los sistemas medianos optimizados por COBOL (B2000, B3000 y B4000) o los sistemas pequeños de arquitectura flexible (B1000).

Antecedentes [ editar ]

Fundada en la década de 1880, Burroughs era la empresa informática más antigua en funcionamiento continuo ( 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 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 una empresa de terceros y cambiaron el nombre de 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ó el B6500 (y los posteriores B6700 y B7700). Las computadoras que usaban esa arquitectura estaban [ cita requerida ] 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 CMOS patentadodiseño de procesador, 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 básicos de Intel durante algunos años.

B5000 [ editar ]

El primer miembro de la primera serie, el B5000, [3] fue diseñado a partir de 1961 por un equipo bajo la dirección de Robert (Bob) Barton . Era una máquina única, muy adelantada a su tiempo. Ha sido catalogado por el influyente científico de la computación 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 reemplazado por el B5500 [5](que utilizaba discos en lugar de almacenamiento de tambor) y el B5700 (que permitía agrupar varias CPU en un disco compartido). Si bien no hubo un sucesor del B5700, la línea B5000 influyó mucho en el diseño del B6500, y Burroughs transfirió el Programa de control maestro ( MCP ) a esa máquina.

Funciones únicas [ editar ]

  • Todo el código vuelve a entrar automáticamente (la figura 4.5 de la monografía de ACM muestra en pocas palabras por qué): los programadores no tienen que hacer nada más para tener ningún código en cualquier lenguaje distribuido entre procesadores que usar solo las dos primitivas simples mostradas. Este es quizás el canónico, pero no significa el único beneficio de estas principales características distintivas de esta arquitectura:
    • Diseño basado en descriptores y etiquetado parcialmente basado en datos
    • El hardware fue diseñado para soportar los requisitos de software.
    • Hardware diseñado para admitir exclusivamente lenguajes de programación de alto nivel
    • Sin lenguaje ensamblador ni ensamblador; todo el software del sistema escrito en una variedad extendida de ALGOL 60 . Sin embargo, ESPOL tenía declaraciones para cada una de las sílabas en la arquitectura.
    • Pocos registros accesibles para programadores
    • Conjunto de instrucciones simplificado
    • Máquina de pila donde todas las operaciones usan la pila en lugar de operandos explícitos
    • Todas las interrupciones y llamadas a procedimientos usan la pila
    • Soporte para sistema operativo de alto nivel (MCP, Programa de control maestro )
  • Soporte para multiprocesamiento asimétrico (maestro / esclavo)
  • Soporte para otros idiomas como COBOL
  • Potente manipulación de cuerdas
  • Un intento de una arquitectura segura que prohíba el acceso no autorizado a los datos o las interrupciones en las operaciones [NB 2]
  • Detección temprana de errores que respalda el desarrollo y la prueba de software.
  • Primera implementación comercial de memoria virtual [NB 3]
    Primer modelo de memoria segmentada
  • Los sucesores todavía existen en las máquinas Unisys ClearPath / MCP
  • Influyó en muchas de las técnicas informáticas actuales.

Diseño de sistema único [ editar ]

El B5000 fue revolucionario 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 un procesador y su conjunto de instrucciones se diseñarían y luego se entregarían a la gente del software, y aún así. Es decir, la mayoría de los otros conjuntos de instrucciones, como el conjunto de instrucciones IBM System / 360 de esa época, y los diseños de conjuntos de instrucciones posteriores, como las arquitecturas de conjuntos de instrucciones x86 , PPC y ARM , son esencialmente arquitecturas tradicionales basadas en conjuntos de instrucciones en lugar de diseños holísticos. como los sistemas Burroughs originales.

El B5000, B5500 y B5700 en modo Word tienen dos modos de direccionamiento diferentes, dependiendo de si está ejecutando un programa principal (SALF desactivado) o una subrutina (SALF activado). Para un programa principal, el campo T de una sílaba de llamada a operando o 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 altos de T y del FlipFlop Mark Stack (MSFF), como se muestra en Direccionamiento relativo B5x00 .

Soporte de idiomas [ editar ]

El B5000 fue diseñado para admitir exclusivamente idiomas de alto nivel. Esto fue en un momento en el que esos lenguajes estaban empezando a cobrar importancia con FORTRAN y luego con COBOL . Algunos consideraron que FORTRAN y COBOL eran lenguajes más débiles cuando se trata de técnicas de software modernas, por lo que se adoptó un lenguaje más nuevo, en su mayoría sin probar, 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 fue 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 fue sobre este tema.

Por lo tanto, el B5000 se basó en un lenguaje muy poderoso. La mayoría de los otros proveedores solo podían soñar con implementar un compilador ALGOL [ dudoso ] y la mayoría de la industria descartó ALGOL por no ser implementable. [ cita requerida ] Sin embargo, un estudiante joven y brillante llamado 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ó periféricamente en el diseño de 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, sin darse cuenta del potencial de ALGOL como lenguaje de programación de sistemas.

El compilador de Burroughs ALGOL fue muy rápido, esto impresionó al científico holandés Edsger Dijkstra cuando presentó un programa para ser compilado en la planta B5000 de Pasadena. Su baraja de cartas se compiló casi de inmediato e inmediatamente quiso varias máquinas para su universidad, la Universidad Tecnológica de Eindhoven en los Países Bajos. El compilador fue rápido por varias razones, pero la razón principal fue 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 de Burroughs ALGOL, a diferencia del lenguaje oficial, requiere que cada variable (u otro objeto) se declare antes de que se use, 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 compilado tan rápido como los lectores de 1000 tarjetas / minuto pudieron leer el código. El programa estaba listo para usarse tan pronto como las tarjetas pasaron por el lector.

Figura 4.5 De ​​la monografía de ACM en las referencias. Elliot Organick 1973.

B6500 y B7500 [ editar ]

El B6500 [7] (entregado en 1969 [8] [9] ) y el B7500 fueron los primeros ordenadores de la única línea de sistemas Burroughs que sobrevivieron hasta nuestros días. Si bien se inspiraron en el B5000, tenían una arquitectura totalmente nueva. Entre las diferencias más importantes se encuentran

  • El B6500 tenía instrucciones de longitud variable con una sílaba de 8 bits en lugar de instrucciones de longitud fija con una sílaba de 12 bits .
  • El B6500 tenía una [NB 4] de 51 bits en lugar de una palabra de 48 bits y usaba 3 bits como etiqueta
  • El B6500 tenía multiprocesamiento simétrico (SMP)
  • El B6500 tenía una pila Saguaro
  • El B6500 tenía arreglos paginados
  • El B6500 tenía registros de pantalla, D1 a D32 para permitir que las subrutinas anidadas accedan a variables en bloques externos.
  • El B6500 utilizó circuitos integrados monolíticos con memoria magnética de película delgada . [8]

B6700 y B7700 [ editar ]

Entre otros clientes se encontraban las cinco universidades de Nueva Zelanda en 1971. [10]

B8500 [ editar ]

La línea B8500 [1] [2] deriva de la D825, [11] una computadora militar inspirada 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] El B8500 nunca se pudo hacer funcionar de manera confiable, y el proyecto se canceló después de 1970, sin haber entregado un sistema completo. [2]

Historia [ editar ]

El concepto central de memoria virtual apareció en los diseños del Atlas de Ferranti y la Computadora del Instituto Rice , y los conceptos centrales de descriptores y arquitectura etiquetada aparecieron en el diseño de la Computadora del Instituto Rice [12] 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, era una computadora de segunda generación que usaba una lógica de transistor discreta y una memoria de núcleo magnético . Las primeras máquinas que reemplazaron la arquitectura B5000 fueron B6500 y B7500. Las máquinas sucesoras siguieron las tendencias de desarrollo de hardware para volver a implementar las arquitecturas en una nueva lógica durante los próximos 25 años, con B5500, B6500, B5700, B6700, B7700, B6800, B7800 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 MCP CMOS ASIC.. Estas máquinas fueron Libra 100 a Libra 500, y Libra 590 se anunció en 2005. Las Libras 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.

Líneas primarias de hardware [ editar ]

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 de Grandes Sistemas 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 a veces incluía instalaciones en las cercanías de 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, manejó la línea B7x00 más grande. Todas las máquinas de ambas líneas eran totalmente compatibles con los objetos, lo que significa que un programa compilado en una podrí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 funcionales. Cuando los modelos Bxx00 fueron reemplazados por los modelos de la Serie A, las diferencias se mantuvieron pero ya no se identificaron fácilmente por el número de modelo.

ALGOL [ editar ]

Los grandes sistemas de Burroughs implementan una arquitectura de pila derivada de ALGOL . El B5000 fue el primer sistema basado en pilas.

Si bien B5000 se diseñó específicamente para admitir ALGOL, esto fue solo un punto de partida. Otros lenguajes orientados a los negocios como COBOL también fueron bien soportados, sobre todo por los poderosos 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 poderosas 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 de #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 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 de sistema.

ESPOL y NEWP [ editar ]

Originalmente, el sistema operativo B5000 MCP se escribió en una extensión de ALGOL extendido llamada ESPOL (Lenguaje orientado a la programación de sistemas ejecutivos). Esto fue reemplazado a mediados o finales de los 70 por un lenguaje llamado NEWP . Aunque NEWP probablemente solo significaba "Nuevo lenguaje de programación", las leyendas rodean el nombre. Una historia común (quizás apócrifa) dentro de Burroughs en ese momento sugirió que provenía de " Sin privilegios de baño ejecutivo. " 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 se le preguntara, una vez más, "¿tiene un nombre todavía?": Respondiendo "nyoooop", lo adoptó como un nombre. NEWP también era una extensión de subconjunto de ALGOL, pero era más segura que ESPOL y eliminó algunas complejidades poco utilizadas de ALGOL. De hecho, el compilador NEWP rechaza todas las construcciones inseguras a menos que se marque un bloque específicamente para permitir esas instrucciones. Este 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 privilegios de root, pueden no ser capaces de hacer esto dependiendo de la configuración elegida por el sitio). Mientras que 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 las 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 como globales dentro del módulo. Las interfaces permiten que un módulo importe y exporte funciones y datos. Los supermódulos permiten agrupar módulos.

DCALGOL y sistemas de control de mensajes (MCS) [ editar ]

El segundo nivel intermedio de seguridad entre el código del sistema operativo (en NEWP) y los programas de usuario (en ALGOL) es para programas de middleware , que están escritos en DCALGOL (comunicaciones de datos ALGOL). Esto se utiliza para la recepción y el envío de mensajes que eliminan los mensajes de las colas de entrada y los coloca en colas para que otros procesos del sistema los manejen. El middleware como COMS (introducido alrededor de 1984) recibe mensajes de toda la red y los envía a procesos de manejo específicos oa un MCS (Sistema de control de mensajes) como CANDE (" C ommand AND E dit", el entorno de desarrollo del programa).

Los MCS son elementos de software que vale la pena señalar: controlan las sesiones de usuario y permiten realizar un seguimiento del estado del usuario sin tener que ejecutar procesos por usuario, ya que muchos usuarios pueden compartir una sola 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, tiene dos pilas, 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, por lo tanto, crear una nueva pila cada vez que un usuario se conecta al sistema. Por lo tanto, puede brindar un servicio 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.

El MCS habló con un coprocesador externo, el DCP (Procesador de control de comunicación de datos). 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 remotos. El DCP y el B6500 se comunicaron mediante mensajes en la memoria, esencialmente paquetes en los términos actuales, y el MCS realizó el procesamiento del lado B6500 de esos mensajes. En los primeros años, el DCP tenía un ensamblador (Dacoma), un programa de aplicación llamado DCPProgen escrito en B6500 ALGOL. Más tarde el NDLEl compilador (Network Definition Language) generó el código DCP y el NDF (archivo de definición de red). 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 incluía nada más que una larga lista de llamadas a estas funciones, una para cada declaración en lenguaje ensamblador. Básicamente, ALGOL actuó como el pase de macro de un ensamblador de macros. 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.

DMALGOL y bases de datos [ editar ]

Otra variante de ALGOL es DMALGOL (Gestión de datos ALGOL). DMALGOL es ALGOL extendido 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 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 el manejo de 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 mediante instalaciones de preprocesamiento que carecen de bucles.

DMALGOL se utiliza para proporcionar rutinas de acceso personalizadas para DMSIIbases de datos. 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 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 del código y el tiempo de ejecución. Se volvió mucho menos utilizado en los últimos años, 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. DMALGOL incluía verbos como "buscar", "bloquear", "almacenar". También los verbos "begintransaction" y "endtransaction"se incluyeron, resolviendo la situación de punto muerto cuando múltiples procesos accedían y actualizaban las mismas estructuras.

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

En años posteriores, dado que el tamaño del código del compilador era menos preocupante, la mayoría de las construcciones de preprocesamiento estaban disponibles en el nivel de usuario de ALGOL. Solo las construcciones inseguras y el procesamiento directo del archivo de descripción de la base de datos permanecen restringidos a DMALGOL.

Arquitectura de pila [ editar ]

En muchos de los primeros sistemas y lenguajes, a los programadores a menudo se les decía 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 se diseñó como una máquina de pila: todos los datos del programa, excepto las matrices (que incluyen cadenas y objetos) se mantuvieron en la pila. Esto significó que las operaciones de pila se optimizaron para la eficiencia. Como una máquina orientada a la 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:

B5000, B5500, B5700
Iniciar P1 (IP1) e Iniciar P2 (IP2) [5] : 6–30
B6500, B7500 y sucesores
MVST (mover pila). [7] : 8-19 [19]

Cada pila y la tabla de referencia de programa (PRT) asociada [NB 5] 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 multitarea). 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 se hace esto.

Entonces, un cambio de proceso procede de esta manera: 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 se ejecuta en la parte superior de la pila de usuarios. Desactiva los temporizadores de proceso 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 lista e invoca la instrucción move_stack, que activa el proceso en la cabecera de la cola lista.

Velocidad y rendimiento de la pila [ editar ]

Algunos de los detractores de la arquitectura B5000 creían que la arquitectura de pila era inherentemente lenta en comparación con las arquitecturas basadas en registros. El truco para 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 que superan la B5000, se puede guardar 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 en 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 volver a compilar, protegiendo así la inversión en software. Se sabe desde hace años que algunos programas se ejecutan con muchas actualizaciones de procesador. Esta aceleración está limitada en máquinas basadas en registros. [ cita requerida ]

Otro punto para 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 todas las máquinas sucesoras de B5000 ahora encajan en un solo chip, así como en las técnicas de soporte de rendimiento, como cachés y canalizaciones de instrucciones.

De hecho, la línea de la serie A de los sucesores del B5000 incluyó el primer mainframe de un solo chip, el Micro-A de finales de la década de 1980. Este chip de "mainframe" (llamado SCAMP para Procesador de Mainframe de la serie A de un solo chip) se encontraba en una placa de PC enchufable basada en Intel.

Cómo se asignan los programas a la pila [ editar ]

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 ( p1 real , p2 ); valor p1 ; - p1 pasado por valor, p2 implícitamente pasado por referencia. comenzar  - - - - - - - - - - - - - - - - - - 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 pueden ser de solo lectura, pero la mayoría no. si r2 > 10 entonces comience - - - - - - - - - - - - - - - - - - - - - - - - - - - Una variable declarada aquí hace que este léxico sea de nivel 4 - - - - - - - - - - - - - - - - - - - - - - - - - - entero n ;
- La declaración de una variable lo convierte en un bloque, que invocará algunos - código de construcción de pila. Normalmente no declarará variables aquí, en las que - caso de que sea una declaración compuesta, no un bloque. ... <== pila de muestra se está ejecutando en algún lugar aquí. terminar ; terminar ; ..... 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 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, por lo tanto, el requisito de declaraciones hacia adelante. Todas las variables declaradas en bloques adjuntos son visibles. Otro caso es que las variables del mismo nombre pueden declararse en bloques internos y estos ocultan efectivamente las variables externas que se vuelven inaccesibles.

El anidamiento léxico es estático, no está relacionado 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 una fuente de Algol como salida (diseñada para resolver algún problema especial) si el método de generación anidaba con frecuencia el procedimiento dentro del procedimiento.

Procedimientos [ editar ]

Los procedimientos se pueden invocar de cuatro formas: normal, llamada, proceso y ejecución.

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

El mecanismo de llamada invoca un procedimiento como una corrutina. Las corrutinas tienen tareas asociadas, donde el control se pasa explícitamente entre las tareas mediante una instrucción CONTINUE. Estos son procesos sincrónicos.

El procesoEl mecanismo invoca un procedimiento como una tarea asincrónica y, en este caso, se configura una pila separada comenzando en el 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 de 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, lo cual es manejado por el tipo de datos EVENT, donde los procesos pueden ESPERAR en un evento hasta que sean causados ​​por otro proceso cooperante. 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 de llamada puede continuar; sin embargo,si el proceso principal muere, todos los procesos secundarios se terminan automáticamente. En una máquina con más de un procesador, los procesos pueden ejecutarse simultáneamente. Este mecanismo de EVENTO es un habilitador básico para el multiprocesamiento además de la multitarea.

Ejecutar tipo de invocación [ editar ]

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 llamarse 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 que estaba integrado en el hardware.

Procedimientos en línea [ editar ]

Una última posibilidad es que un procedimiento se pueda declarar INLINE, es decir, cuando el compilador ve una referencia al mismo, el código para el procedimiento se genera en línea para ahorrar la sobrecarga de una llamada a procedimiento; esto se hace mejor para pequeños fragmentos de código. Las funciones en línea son similares a las macros parametrizadas como C #defines, excepto que no tiene problemas con los parámetros que puede hacer con las macros. Esta instalación está disponible en NEWP.

Llamadas asincrónicas [ editar ]

En el programa de ejemplo solo se utilizan llamadas normales, por lo que toda la información estará en una sola pila. Para las llamadas asincrónicas, la pila se dividiría en varias pilas para que los procesos compartan datos pero se ejecuten de forma asincrónica.

Mostrar registros [ editar ]

Una optimización de hardware de 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 se sale de los procedimientos y ningún software puede acceder a ellos. Hay 32 registros D, que es lo que limita 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]). Suponga 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 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. 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 usa palabras de control para diferenciarlas).

Como puede ver, esto es bastante ineficiente solo 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 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 los registros D, el acceso a entidades en entornos externos y globales es igual de eficiente como acceso a variable local.

Datos de etiqueta D: dirección de pareja, comentariosRegistrarse
| 0 | n | (4, 1) El entero n (declarado al ingresar a un bloque, no 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 r2 real| ----------------------- || 0 | r1 | (3, 4) El verdadero r1| ----------------------- || 1 | p2 | (3, 3) Una referencia SIRW ag 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) El verdadero g | ----------------------- || 0 | f | (2, 5) La verdadera f | ----------------------- || 0 | k | (2, 4) El entero k | ----------------------- || 0 | j | (2, 3) El entero j | ----------------------- || 0 | yo | (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 enlace al marco de pila anterior.| ======================= | - Fondo de 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 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 apunta a otro entorno de proceso D [2] en la parte superior de su propia pila de proceso. 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 directamente direccionable y, en cambio, hace que el entorno D [2] en otra pila de procesos sea directamente direccionable. Así es como se implementan las llamadas a la biblioteca. En tal llamada de pila cruzada,el código de llamada y el código llamado podrían incluso provenir 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 segmento de código, que es compartido por 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 que existir en una pila de proceso. Esta función se utilizó 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 noventa, esta capacidad se implementó como una característica del lenguaje como BLOQUES DE ESTRUCTURA y, combinada con la 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 B5000 usó una forma de orientación a objetos mucho antes de que se usara 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 recopilarían y el código de la máquina se escribiría para usar direcciones de memoria planas de 16 bits o 32 bits o incluso 64 bits. Estas direcciones pueden contener cualquier cosa, por lo que una escritura a la 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, por lo general ocupando una palabra; la precisión doble o las variables complejas ocuparían dos. Las matrices no eranalmacenado en esta área, solo se tenía un descriptor de una palabra para la matriz. Por lo tanto, en cada nivel léxico, el requisito de almacenamiento total no fue muy grande: docenas, cientos o algunos miles en casos extremos, ciertamente no un recuento que requiera 32 bits o más. Y de hecho, esto se reflejó en la forma de la instrucción VALC (llamada de valor) que cargó 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 concatenaron con el siguiente byte para dar un campo de direccionamiento de catorce bits. El código que se está ejecutando estaría en algún nivel léxico, digamos seis: esto significaba que solo los niveles léxicos cero a seis eran válidos, por lo que solo se necesitaban tres bits para especificar el nivel léxico deseado. La parte de dirección de la operación VALC reservó solo tres bits para ese propósito,y el resto está disponible para hacer referencia a entidades en ese nivel y en niveles inferiores. Un procedimiento profundamente anidado (por lo tanto, a 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-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 cargó datos: los códigos de operación para ADD, MULT, etc. no hicieron direccionamiento, trabajando completamente en los elementos superiores de la pila.para el nivel dieciséis en adelante, se necesitarían cinco bits para especificar la elección de los niveles 0-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 hicieron direccionamiento, trabajando completamente en los elementos superiores de la pila.para el nivel dieciséis en adelante, se necesitarían cinco bits para especificar la elección de los niveles 0-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 hicieron direccionamiento, trabajando completamente en los elementos superiores de la pila.

Mucho más importante es que este método significó que muchos errores disponibles para los sistemas que emplean direccionamiento plano no podrían ocurrir porque eran simplemente indescriptibles incluso a nivel de código de máquina. Una tarea no tenía forma de dañar la memoria en uso por otra tarea, porque no tenía forma de desarrollar su dirección. El hardware verificaría las compensaciones de un registro D específico con el límite del 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 solo podría ir a una ubicación de almacenamiento de datos, no a una que tenga un puntero o un descriptor de matriz,etc. y ciertamente no a una ubicación que contenga un código de máquina.

Almacenamiento de matrices [ editar ]

Las matrices no se almacenaron contiguas en la memoria con otras variables, a cada una se le otorgó su propio espacio de direcciones, que se ubicaba 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 el desplazamiento en el espacio de direcciones de la matriz, con verificación de límite proporcionada por el hardware. Si la longitud de una matriz supera las 1.024 palabras, la matriz se segmentará y el índice se convertirá en un índice de segmento y un desplazamiento en el segmento indexado. 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,qué fila se indexaría con j como para una matriz unidimensional, y así sucesivamente para dimensiones más altas. La comprobació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 de enteros simple para calcular el desplazamiento donde el elemento A (i, j, k) se encontraría en ese único secuencia. La matriz equivalente unidimensional, 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 resultar en una violación de los límites de la matriz de secuencia única; en otras palabras, los índices no se comprobaron individualmente.

Debido a que el almacenamiento de una matriz no estaba limitado en cada lado por el almacenamiento de otros elementos, fue fácil para el sistema "cambiar el tamaño" de una matriz, aunque no se pudo cambiar el número de dimensiones porque los compiladores requerí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 (o de mayor dimensión) habituales. Por lo tanto, en dos dimensiones, una matriz irregular tendría filas de diferentes tamaños. Por ejemplo, dada una gran matriz A (100,100) de valores en su mayoría 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 lo largo de esa fila.

Debido a que las matrices de más de 1024 palabras estaban segmentadas, pero las matrices más pequeñas no, en un sistema que tenía poca memoria real, aumentar el tamaño declarado de una colección de matrices de scratchpad de 1000 a 1050 podría significar que el programa se ejecutaría con mucho menos " thrashing "ya que sólo los segmentos individuales más pequeños en uso se necesitaban en la memoria. 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ó a no inicializar una matriz a cero al principio, normalmente una omisión imprudente.

Ventajas de la estructura de la pila [ editar ]

Una cosa buena acerca de la estructura de la 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. Compare eso con los volcados de núcleo y los paquetes de intercambio de otros sistemas.

Otra cosa sobre la estructura de la pila es que los programas son implícitamente recursivos. No se esperaba que FORTRAN apoyara 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 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 (al igual que cualquier otro compilador FORTRAN), pero a diferencia de muchas otras computadoras, en un sistema basado en pilas, las devoluciones de tales llamadas también se realizaron correctamente. Esto podría tener efectos extraños, como con 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 verificación de errores que otras implementaciones contemporáneas de FORTRAN. [ cita requerida ] Por ejemplo, para las subrutinas y funciones, verificó que fueran invocadas con el número correcto de parámetros, como es normal para los compiladores de estilo ALGOL. En otras computadoras, estos desajustes eran causas comunes de fallas. De manera similar con la verificación enlazada a la matriz: los programas que se habían utilizado 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 e implementación de lenguajes, incluido el Simula orientado a objetos (un superconjunto de ALGOL) e Iverson , el diseñador de APLdeclaró que la implementación de APL de Burroughs era la mejor que había visto. [ cita requerida ] John McCarthy , el diseñador de lenguaje de LISP no estuvo de acuerdo, ya que LISP se basó en un código modificable [ cita requerida ] , no le gustaba el código no modificable de B5000 [ cita requerida ] , pero la mayoría de las implementaciones de LISP se ejecutarían en un formato interpretativo medio ambiente de todos modos.

El almacenamiento requerido para los múltiples procesos provino de la agrupación de memoria del sistema según sea necesario. No era necesario realizar SYSGEN en los sistemas Burroughs como en los sistemas de la competencia para preconfigurar las particiones de memoria en las que ejecutar las tareas.

Arquitectura etiquetada [ editar ]

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 son que se basa en etiquetas y descriptores.

En el B5000 original, un bit de bandera en cada control o palabra numérica [NB 7] se apartó para identificar la palabra como palabra de control o palabra numérica. Esto fue parcialmente 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 advirtió que la distinción numérica / palabra de control de 1 bit era una idea poderosa y esto se amplió a tres bits fuera de la palabra de 48 bits en una etiqueta. Los bits de datos son los bits 0–47 y la etiqueta está en los bits 48–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 ser escritas por 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 usaban con fines de ingeniería, como un campo de corrección de errores del código Hamming , pero los programadores nunca los vieron.

La encarnación actual de estas máquinas, Unisys ClearPath ha ampliado las etiquetas a una etiqueta de cuatro bits. El nivel de microcódigo que especifica etiquetas de cuatro bits se denomina 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 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 la palabra del sistema el formato puede haber cambiado.

Las palabras de etiqueta 1 representan direcciones de datos en pila. El IRW normal simplemente almacena un par de direcciones para los 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.

Las palabras de la etiqueta 5 son descriptores, que se describen con más detalle en la siguiente sección. Las palabras de etiqueta 5 representan direcciones de datos fuera de la pila.

La etiqueta 7 es la palabra de control de programa que describe un punto de entrada de procedimiento. Cuando los operadores golpean un PCW, se ingresa el procedimiento. El operador ENTR ingresa explícitamente un procedimiento (rutina de no devolución de valor). Las funciones (rutinas de devolución de 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 segmento 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 tanto, el código es reentrante y compartido.

La etiqueta 3 representa las propias palabras de código, que no aparecerán en la pila. La etiqueta 3 también se utiliza para las palabras de control de pila MSCW, RCW, TOSCW.

Figura 9.2 De la monografía de ACM en las referencias. Elliot Organick 1973.

Arquitectura basada en descriptores [ editar ]

La figura de la izquierda muestra cómo la arquitectura del sistema grande de Burroughs era fundamentalmente una arquitectura de hardware para la programación orientada a objetos , algo que todavía no existe en las arquitecturas convencionales.

Conjuntos de instrucciones [ editar ]

Hay tres conjuntos de instrucciones distintos para los sistemas grandes de Burroughs. Los tres se basan en sílabas cortas que encajan uniformemente en las palabras.

B5000, B5500 y B5700 [ editar ]

Los programas en un B5000, B5500 y B5700 se componen de sílabas de 12 bits , cuatro por palabra. La arquitectura tiene dos modos, el modo de palabras y el modo de caracteres, y cada uno tiene un repertorio de sílabas separado. Un procesador puede ser estado de control o estado normal, y ciertas sílabas solo se permiten en el estado de control. La arquitectura no permite direccionar registros o almacenamiento directamente; todas las referencias son 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 bits en una sílaba de 0 (bit alto) a 11 (bit bajo)

B6500, B7500 y sucesores [ editar ]

Los programas se componen de sílabas de 8 bits , que pueden ser Name Call, Value Call o formar un operador, que pueden tener una longitud de una a doce sílabas. Hay menos de 200 operadores , todos los cuales encajan en sílabas de 8 bits. Muchos de estos operadores son polimórficos según el 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 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.

Varios procesadores [ editar ]

La línea B5000 también fue pionera en tener múltiples procesadores conectados juntos en un bus de alta velocidad. La línea B7000 podría tener hasta ocho procesadores, siempre que al menos uno sea un módulo de E / S. RDLK es una forma de sincronización de muy bajo nivel entre procesadores. El nivel alto utilizado por los programas de usuario es el tipo de datos EVENT. El tipo de datos EVENT tuvo alguna sobrecarga del sistema. Para evitar esta sobrecarga, se puede utilizar una técnica de bloqueo especial llamada cerraduras Dahm (nombradas en honor a un gurú del software de Burroughs, Dave Dahm).

Los operadores notables son:

HEYU - enviar una interrupción a otro procesador
RDLK - Operador de semáforo de bajo nivel: cargue el registro A con la ubicación de memoria dada por el registro A y coloque el valor en el registro B en esa ubicación de memoria en un solo ciclo ininterrumpido. El compilador de Algol produjo código para invocar este operador a través de una función especial que habilitó 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 reciba una interrupción

Con poca frecuencia, dos procesadores pueden enviarse simultáneamente entre sí un comando 'HEYU', lo que resulta en un bloqueo conocido como ' abrazo mortal '.

Influencia del B5000 [ editar ]

La influencia directa del B5000 se puede ver en la gama actual de mainframes ClearPath de Unisys, que son los descendientes directos del B5000 y todavía tienen el sistema operativo MCP después de 40 años de desarrollo constante. Esta arquitectura ahora se llama emode (para el modo de emulación) ya que la arquitectura B5000 se ha implementado en máquinas construidas a partir de procesadores Intel Xeon que ejecutan el conjunto de instrucciones x86 como el 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 esto se eliminó [ cita requerida ] , por lo que a menudo puede escuchar que las máquinas sucesoras de B5000 se denominan "máquinas emode".

Las máquinas B5000 se programaron exclusivamente en lenguajes de alto nivel; no hay ensamblador.

La arquitectura de la pila 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, señalando que DUP, DROP y SWAP de Forth procedían 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 soviética de mainframes y supercomputadoras Elbrus . Las dos primeras generaciones de la serie incluían memoria etiquetada y CPU basadas en pila que se programaron solo en lenguajes de alto nivel. Existía una especie de lenguaje ensamblador para ellos, 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. Las generaciones posteriores de la serie, sin embargo, cambiaron de esta arquitectura a las CPU VLIW similares a EPIC .

Los diseñadores de Hewlett-Packard del sistema empresarial HP 3000 habían utilizado un B5500 y estaban muy impresionados por su hardware y software; tenían como objetivo construir una minicomputadora de 16 bits con software similar. Varias otras divisiones de HP crearon máquinas apilables de minicomputadoras o microprocesadores similares. El trabajo de Bob Barton en notación polaca inversa (RPN) también se abrió camino en las calculadoras HP comenzando con la 9100A, y en particular con la HP-35 y las calculadoras posteriores.

Los sistemas NonStop diseñados por Tandem Computers a fines de la década de 1970 y principios de la de 1980 también eran máquinas apiladas de 16 bits, influenciadas indirectamente por el B5000 a través de la conexión HP 3000, ya que varios de los primeros ingenieros de Tandem estaban anteriormente con HP. Alrededor de 1990, estos sistemas migraron a la arquitectura MIPS RISC, pero continuaron admitiendo la ejecución de binarios de máquina de pila mediante traducción de código objeto o emulación directa. En algún momento después de 2000, estos sistemas migraron a la arquitectura Itanium y continuaron ejecutando los binarios de la máquina de pila heredada.

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 requerida ]

Otra faceta de la arquitectura B5000 era que era una arquitectura segura que se ejecutaba directamente en el hardware. Esta técnica tiene descendientes en las máquinas virtuales de hoy [ cita requerida ] en sus intentos de proporcionar entornos seguros. Un producto notable de este tipo es Java JVM, que proporciona una caja de arena segura en la que se ejecutan las aplicaciones.

El valor del enlace 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 era el único programa de control, pero el soporte proporcionado por esas máquinas sigue siendo inferior al proporcionado en el máquinas donde el conjunto de instrucciones B5000 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.

Ver también [ editar ]

  • Sistemas medianos de Burroughs
  • Sistemas pequeños de Burroughs
  • CANDE
  • Lenguaje de definición de red (NDL)
  • Lenguaje de flujo de trabajo (WFL)
  • Punto flotante octal

Notas [ editar ]

  1. ^ Por ejemplo, sílabas de 12 bits para B5000, sílabas de 8 bits para B6500
  2. ^ Hubo problemas de seguridad
  3. ^ A menos que haya contado el Ferranti Atlas como una máquina comercial.
  4. ^ Sin contar los controles de error
  5. ^ a b c Solo para B5000, B5500 y B5700
  6. ^ Solo para B6500, B7500 y sucesores
  7. ^ No había ningún bit de bandera en las palabras que contenían datos de caracteres o código

Referencias [ editar ]

  • The Extended ALGOL Primer (tres volúmenes), Donald J. Gregory.
  • Arquitectura informática: un enfoque estructurado, R. Doran, Academic Press (1979).
  • Stack Computers: The New Wave, Philip J. Koopman, disponible en: [1]
  • Manuales de B5500, B6500, B6700, B6800, B6900, B7700 en: bitsavers.org
  1. ^ a b c John T. Lynch (agosto de 1965), "The Burroughs B8500" (PDF) , Datamation : 49–50
  2. ^ a b c d George Gray (octubre de 1999), "Burroughs Third-Generation Computers" , Unisys History Newsletter , 3 (5), archivado desde el original el 26 de septiembre de 2017
  3. ^ Burroughs (1963), Las características operativas de los procesadores para Burroughs B5000 (PDF) , Revisión A, 5000-21005
  4. John Mashey (15 de agosto de 2006). "Diseños admirados / diseños para estudiar" . Grupo de noticiascomp.arch . Usenet: [email protected] . Consultado el 15 de diciembre de 2007 . 
  5. ^ a b Burroughs (mayo de 1967), Manual de referencia del sistema de procesamiento de información de Burroughs B5500 (PDF) , 1021326
  6. ^ Tomado de "Tabla 5-1 Tabla de direccionamiento relativo". Manual de referencia de sistemas de procesamiento de información de Burroughs B5500 (PDF) . Documentación de sistemas. Corporación Burroughs. Mayo de 1967. p. 5-4. 1021326.
  7. ^ a b Manual de referencia del sistema de procesamiento de información de Burroughs B6500 (PDF) , Burroughs, septiembre de 1969, 1043676
  8. ^ a b "Narrativa histórica de la década de 1960; Estados Unidos vs IBM, prueba documental 14971, parte 2" . ed-thelen.org . Gobierno de los Estados Unidos. 22 de julio de 1980. p. 648 (409) . Consultado el 21 de febrero de 2019 . URL alternativa
  9. ^ Burroughs Corporation (1969), Informe de estado de Burroughs B6500 (película), Nigel Williams (publicado el 8 de agosto de 2015 ), Código de tiempo: estado de 1969 - 0: 00-0: 52, 6: 04-7: 01, 8:14 ; fecha - 3:40, 4:21 , consultado el 4 de marzo de 2019
    • Tasa de envíos, primeras 16 computadoras: burroughs :: B6500 6700 :: CUBE XVI B6500 Estado Abr70 . Abril de 1970. págs. 1-2.
  10. ^ "Pantallas de historial de computación: cuarto piso" . Universidad de Auckland . Consultado el 18 de mayo de 2020 .
  11. ^ Anderson, James P .; Hoffman, Samuel A .; Shifman, Joseph; Williams, Robert J. (1962), "D825 - a multiple-computer system for command & control", Proceedings of the December 4–6, 1962, Fall Joint Computer Conference , AFIPS Conference Proceedings, Volumen 24, págs. 86–96 , doi : 10.1145 / 1461518.1461527 , S2CID 1186864 
  12. ^ Henry M. Levy , "Capítulo 2 Arquitecturas de descriptores tempranos" (PDF) , Sistemas informáticos basados ​​en capacidades , Prensa digital
  13. ^ "Anuncio de B5500" (PDF) . Burroughs. 11 de agosto de 1964.
  14. ^ Imagen de SCAMP en las computadoras antiguas de Dave
  15. ^ Reitman, Valerie (18 de enero de 1989), "Unisys listo para ofrecer una computadora central de escritorio" , The Philadelphia Inquirer , consultado el 16 de abril de 2011
  16. ^ "Unisys acelera el renacimiento de mainframe con nuevos servidores ClearPath Enterprise, nuevos precios agresivos. - Business Wire - HighBeam Research" (Comunicado de prensa). 8 de junio de 1998. Archivado desde el original el 16 de mayo de 2011.
  17. ^ "Libra 595" . Unisys.
  18. ^ "Libra 750" . Unisys.
  19. ^ Organick, Elliot (1973). Organización de sistemas informáticos . ACM . págs. 115-117. ISBN 0-12-528250-8.

Lectura adicional [ editar ]

  • Barton, Robert S. "Un nuevo enfoque para el diseño funcional de una computadora digital" Actas de la Western Joint Computer Conference. ACM (1961).
  • Burroughs B 5000 Historia oral , Instituto Charles Babbage , Universidad de Minnesota. La serie de computadoras Burroughs 5000 es analizada por personas responsables de su desarrollo y comercialización desde 1957 hasta la década de 1960 en una conferencia de 1985 patrocinada por AFIPS y Burroughs Corporation .
  • Gray, George (marzo de 1999). "Algunas computadoras de transistores Burroughs" . Boletín de Historia de Unisys . 3 (1). Archivado desde el original el 1 de octubre de 2016.
  • Gray, George (octubre de 1999). "Computadoras de tercera generación de Burroughs" . Boletín de Historia de Unisys . 3 (5). Archivado desde el original el 26 de septiembre de 2017.
  • Hauck, EA, Dent, Ben A. "Burroughs B6500 / B7500 Stack Mechanism", SJCC (1968) págs. 245-251.
  • McKeeman, William M. "Diseño informático dirigido por el lenguaje", Conferencia conjunta sobre informática de otoño, (1967) págs. 413–417.
  • Organick, Elliot I. "Organización del sistema informático La serie B5700 / B6700" , Academic Press (1973).
  • Waychoff, Richard, "Historias del B5000 y las personas que estuvieron allí" , 27 de septiembre de 1979. [2]
  • Allweiss, Jack. "The Burroughs B5900 y E-Mode Un puente a la informática del siglo XXI" , revisado en 2010.
  • Martin, Ian. "'Demasiado adelantado a su tiempo': Gran Bretaña, Burroughs y la banca en tiempo real en la década de 1960" , Reunión anual de la Sociedad para la Historia de la Tecnología, 20 de septiembre al 3 de octubre de 2010, Tacoma, EE. UU.

Enlaces externos [ editar ]

  • Página de Burroughs de Ian Joyner
  • Burroughs B5900 y E-Mode: un puente hacia la informática del siglo XXI - Jack Allweiss
  • (archivo web de :) Ralph Klimek en el B7800 en la Universidad de Monash
  • "Early Burroughs Machines" , Museo de la Computación de la Universidad de Virginia .
  • "Organización de sistemas informáticos" , Serie de monografías ACM.
  • Índice de manuales de B8500
  • Proyecto de emulación B5500 Proyecto para crear un emulador funcional para el sistema informático Burroughs B5500.
  • "Película y transcripción de Burroughs B6500"