WikiDer > Большие системы Берроуза

Эта статья тон или стиль могут не отражать энциклопедический тон используется в Википедии. См. Википедию руководство по написанию лучших статей для предложений. (Август 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

В Группа крупных систем Берроуза произвела семью из больших 48 бит мэйнфреймы с помощью штабелеукладчик наборы инструкций с плотным слоги.^{[NB 1]} Первой машиной в семействе была B5000 1961 года. Она была оптимизирована для компиляции АЛГОЛ 60 программы очень хорошо, используя однопроходные компиляторы. Он превратился в B5500. Последующие серьезные изменения включают линейку B6500 / B6700 и ее преемников, а также отдельную линейку B8500.

В 1970-х годах Корпорация Берроуз была организована в три подразделения с очень разными архитектурами линейки продуктов для бизнес-компьютерных систем высшего, среднего и начального уровня. Линия продуктов каждого подразделения выросла из различных концепций оптимизации набора команд компьютера для определенных языков программирования. Термин «крупные системы Берроуза» относится ко всем этим линейкам продуктов для крупных систем вместе, в отличие от КОБОЛ-оптимизированный Средние системы (B2000, B3000 и B4000) или гибкую архитектуру Малые системы (B1000).

Фон

Основанная в 1880-х годах, Burroughs была старейшей непрерывно действующей компанией в области вычислительной техники (Братья Эллиотт была основана до Берроуза, но не производила вычислительных устройств в 19 веке). К концу 1950-х годов его вычислительное оборудование все еще ограничивалось электромеханическими. бухгалтерские машины такой как Sensimatic. Ему нечего было конкурировать со своими традиционными соперниками. IBM и NCR, которые начали производить более крупные компьютеры, или недавно основанные Univac. В 1956 году они купили стороннюю компанию и переименовали ее дизайн в B205.

Первая машина Берроуза, B5000, была разработана в 1961 году, и Берроуз стремился решить ее поздний выход на рынок с помощью стратегии совершенно другой конструкции, основанной на самых передовых вычислительных идеях, доступных в то время. Хотя архитектура B5000 мертва, она вдохновила B6500 (и последующие B6700 и B7700). Компьютеры, использующие эту архитектуру, были^{[нужна цитата]} все еще в производстве как Unisys Серверы ClearPath Libra, на которых работает усовершенствованная, но совместимая версия MCP операционная система, впервые представленная в B6700. Третья и самая крупная линейка, B8500,^[1][2] не имел коммерческого успеха. Помимо фирменного CMOS дизайн процессора, Unisys также использует Intel Xeon процессоры и запуски MCP, Майкрософт Виндоус и Linux операционные системы на своих серверах Libra; использование нестандартных микросхем было постепенно исключено, и к 2018 году серверы Libra уже несколько лет были исключительно товаром Intel.

B5000

Первый член первой серии, B5000,^[3] был разработан в 1961 году командой под руководством Роберт (Боб) Бартон. Это была уникальная машина, намного опередившая свое время. Он был включен в список влиятельных ученых-информатиков. Джон Маши как одна из архитектур, которой он восхищается больше всего. «Я всегда думал, что это один из самых новаторских примеров комбинированного проектирования аппаратного и программного обеспечения, который я видел, и намного опережающий свое время».^[4] На смену B5000 пришел B5500.^[5] (в котором использовались диски, а не барабанное хранилище) и B5700 (который позволял кластеризовать несколько процессоров вокруг общего диска). Хотя у B5700 не было преемника, линейка B5000 сильно повлияла на дизайн B6500, и Берроуз перенес Программа Master Control (MCP) к этой машине.

Уникальные черты

• Весь код автоматически повторно въезжающий (рис. 4.5 из монографии ACM показывает в двух словах почему): программистам не нужно ничего делать, чтобы код на любом языке был распределен между процессорами, кроме как использовать только два показанных простых примитива. Это, возможно, каноническое, но далеко не единственное преимущество этих основных отличительных черт этой архитектуры:
  • Частично на основе данных отмечен и дескриптор-основанный дизайн
  • Оборудование было разработано с учетом требований программного обеспечения
  • Оборудование, предназначенное исключительно для поддержки языки программирования высокого уровня
  • Нет язык ассемблера или ассемблер; все системное программное обеспечение, написанное на расширенном разнообразии АЛГОЛ 60. Тем не мение, ESPOL имел утверждения для каждого из слогов в архитектуре.
  • Мало регистров, доступных программисту
  • Упрощенный Набор инструкций
  • Штабелеукладчик где все операции используют стек, а не явные операнды
  • Все прерывания и вызовы процедур используют стек
  • Поддержка высокого уровня Операционная система (MCP, Программа Master Control)
• Поддержка для асимметричный (ведущий / ведомый) многопроцессорность
• Поддержка других языков, таких как КОБОЛ
• Мощное управление струнами
• Попытка создать безопасную архитектуру, запрещающую несанкционированный доступ к данным или сбои в работе^{[NB 2]}
• Раннее обнаружение ошибок, поддерживающее разработку и тестирование программного обеспечения
• Первая коммерческая реализация виртуальной памяти^{[NB 3]}
  Первая сегментированная модель памяти
• Преемники все еще существуют в Unisys Машины ClearPath / MCP
• Влиял на многие современные вычислительные техники

В нижеследующем обсуждении обозначения машин B5000, A Series и ClearPath / MCP используются взаимозаменяемо, хотя это без нужды объединяет функции и концепции линий B5000 и B8500 с линейкой B6500.

Уникальный дизайн системы

B5000 был революционным в то время, поскольку его архитектура и набор команд были разработаны с учетом потребностей программного обеспечения. Это было большим отходом от дизайна компьютерных систем того времени, когда процессор и его набор команд должны были быть спроектированы, а затем переданы программистам, и это до сих пор. То есть большинство других наборов инструкций, таких как IBM System / 360 набор инструкций той эпохи, а также более поздние конструкции наборов инструкций, такие как x86, PPC, и РУКА Архитектуры наборов команд, по сути, представляют собой традиционные архитектуры, основанные на наборах команд, а не целостные конструкции, подобные исходным системам Burroughs.

B5000, B5500 и B5700 в режиме Word имеют два разных режима адресации в зависимости от того, выполняет ли он основную программу (SALF выключен) или подпрограмму (SALF включен). Для основной программы поле T слога вызова операнда или вызова дескриптора относится к справочной таблице программы (PRT). Для подпрограмм тип адресации зависит от трех старших битов T и от метки стека меток (MSFF), как показано на Относительная адресация B5x00.

Языковая поддержка

B5000 был разработан исключительно для поддержки языков высокого уровня. Это было в то время, когда такие языки только становились популярными с FORTRAN а потом КОБОЛ. Некоторые считали FORTRAN и COBOL более слабыми языками, когда дело доходит до современных программных технологий, поэтому был принят более новый, в основном непроверенный язык, АЛГОЛ-60. Диалект Алгола, выбранный для B5000, был Эллиотт АЛГОЛ, впервые разработанная и реализованная МАШИНА. Hoare на Эллиотт 503. Это было практическое расширение ALGOL с инструкциями ввода-вывода (которые ALGOL проигнорировал) и мощными инструкциями по обработке строк. Премия Тьюринга лекция была на эту тему.

Таким образом, B5000 был основан на очень мощном языке. Большинство других производителей могли только мечтать о реализации компилятора ALGOL.^{[сомнительный – обсуждать]} и большинство в отрасли отвергали АЛГОЛ как нереализуемый.^{[нужна цитата]} Однако яркую юную студентку по имени Дональд Кнут ранее реализовал АЛГОЛ 58 на более ранней машине Берроуза в течение трех месяцев его летних каникул, и он был периферийно вовлечен в разработку B5000 в качестве консультанта. Многие списали ALGOL, ошибочно полагая, что языки высокого уровня не могут обладать такой же мощью, как ассемблер, и, таким образом, не осознавая потенциал ALGOL как языка системного программирования.

Компилятор Burroughs ALGOL работал очень быстро - это впечатлило голландского ученого. Эдсгер Дейкстра когда он представил программу для компиляции на заводе B5000 в Пасадене. Его колода карт была собрана почти сразу, и он сразу захотел несколько машин для своего университета, Эйндховенский технологический университет в Нидерландах. Компилятор был быстрым по нескольким причинам, но основная причина заключалась в том, что это был однопроходный компилятор. Ранние компьютеры не имели достаточно памяти для хранения исходного кода, поэтому компиляторам (и даже ассемблерам) обычно приходилось читать исходный код более одного раза. Синтаксис Burroughs ALGOL, в отличие от официального языка, требует, чтобы каждая переменная (или другой объект) была объявлена ​​до ее использования, поэтому можно написать компилятор ALGOL, который считывает данные только один раз. Эта концепция имеет глубокие теоретические последствия, но также позволяет очень быстро компилировать. Большие системы Берроуза могли компилироваться настолько быстро, насколько они могли читать исходный код из перфокарты, и у них были самые быстрые устройства чтения карт в отрасли.

Мощный компилятор Burroughs COBOL также был однопроходным и столь же быстрым. Программа на языке COBOL на 4000 карт, скомпилированная так быстро, как считыватели на 1000 карт в минуту могли прочитать код. Программа была готова к использованию, как только карты прошли через ридер.

Рисунок 4.5 Из монографии ACM в списке литературы. Эллиот Органик 1973.

B6500 и B7500

B6500^[7] (поставка 1969 г.^[8][9]) и B7500 были первыми компьютерами в единственной линейке систем Burroughs, дожившими до наших дней. Хотя они были вдохновлены B5000, у них была совершенно новая архитектура. Среди наиболее важных отличий были

• B6500 имел инструкции переменной длины с 8-битный слог вместо инструкций фиксированной длины с 12-битный слог.
• B6500 имел 51-битный^{[NB 4]} вместо 48-битного слова и использовал 3 бита в качестве тег
• B6500 имел Симметричная многопроцессорная обработка (SMP)
• У B6500 был Стек Сагуаро
• B6500 имел страничные массивы
• B6500 имел Регистры дисплея, с D1 по D32 чтобы позволить вложенным подпрограммам обращаться к переменным во внешних блоках.
• В B6500 используется монолитный интегральные схемы с магнитным тонкопленочная память.^[8]

B6700 и B7700

Среди других клиентов были все пять университетов Новой Зеландии в 1971 году.^[10]

B8500

B8500^[1][2] линия происходит от D825,^[11] военный компьютер, вдохновленный B5000.

B8500 был разработан в 1960-х годах как попытка объединить конструкции B5500 и D825. В системе используется монолитная интегральные схемы с магнитным тонкопленочная память. Архитектура использовала 48-битное слово, стек и дескрипторы, такие как B5500, но не рекламировалась как совместимая снизу вверх.^[1] B8500 никогда не удалось заставить работать надежно, и проект был отменен после 1970 года, так и не поставив законченную систему.^[2]

История

Эта секция нуждается в расширении. Вы можете помочь добавляя к этому. (Июнь 2008 г.)

В нижеследующем обсуждении обозначения машин B5000, A Series и ClearPath / MCP используются взаимозаменяемо, хотя это без нужды объединяет функции и концепции линий B5000 и B8500 с линией B6500.

Центральная концепция виртуальная память появился в дизайне Ферранти Атлас и Компьютер Института Райса, а центральные концепции дескрипторов и помеченной архитектуры появились в дизайне компьютера Института Райса.^[12] в конце 1950-х гг. Однако, даже если эти проекты оказали прямое влияние на Берроуза, архитектуры B5000, B6500 и B8500 сильно отличались от архитектуры Atlas и машины Rice; они также сильно отличаются друг от друга.

Первой из больших систем Берроуза была B5000. Разработанный в 1961 году, это был компьютер второго поколения, использующий дискретный транзистор логика и память на магнитном сердечнике. Первыми машинами, которые заменили архитектуру B5000, были B6500 и B7500. Машины-преемники следовали тенденциям развития аппаратного обеспечения, чтобы в течение следующих 25 лет повторно реализовать архитектуры с новой логикой, выпустив B5500, B6500, B5700, B6700, B7700, B6800, B7800 и, наконец, серию Burroughs A. После слияния, в ходе которого Берроуз приобрел Sperry Corporation и изменил свое название на Unisys, компания продолжала разрабатывать новые машины на базе MCP CMOS ASIC. Это были машины от Libra 100 до Libra 500, а Libra 590 была анонсирована в 2005 году. Более поздние версии Libra, в том числе 590, также включают процессоры Intel Xeon и могут запускать архитектуру больших систем Burroughs в режиме эмуляции, а также на процессорах MCP CMOS. . Неясно, продолжит ли Unisys разработку новых MCP CMOS ASIC.

Основные линейки оборудования

Проектирование, разработка и производство оборудования и программного обеспечения были разделены между двумя основными офисами: Округ Ориндж, Калифорния, и окраины Филадельфия. Первоначальный завод крупных систем, который разработал B5000 и B5500, располагался в Пасадена, Калифорния но переехал в Город промышленности, Калифорния, где был разработан B6500. Местоположение округа Ориндж, которое располагалось на заводе в Миссия Вьехо, Калифорния но иногда включают объекты в близлежащих Ирвин и Lake Forest, отвечал за меньшую линию B6x00, в то время как операции на восточном побережье, базирующиеся в Тредиффрин, Пенсильвания, обработал большую линию B7x00. Все машины обеих линий были полностью объектно-совместимыми, то есть программа, скомпилированная на одной, могла быть выполнена на другой. В более новых и больших моделях были инструкции, которые не поддерживались на более старых и более медленных моделях, но оборудование при обнаружении нераспознанной инструкции вызывало функцию операционной системы, которая ее интерпретировала. Другие отличия включают в себя то, как выполнялись переключение процессов и ввод / вывод, а также функции обслуживания и холодного запуска. Более крупные системы включали аппаратное планирование процессов и более функциональные модули ввода / вывода и более функциональные процессоры обслуживания. Когда модели Bxx00 были заменены моделями серии A, различия были сохранены, но их уже нельзя было легко идентифицировать по номеру модели.

АЛГОЛ

Большие системы Берроуза реализуют производный от АЛГОЛА стековая архитектура. B5000 была первой системой на основе стека.

Хотя B5000 был специально разработан для поддержки ALGOL, это было только отправной точкой. Другие бизнес-ориентированные языки, такие как COBOL, также хорошо поддерживались, в первую очередь мощными строковыми операторами, которые были включены для разработки быстрых компиляторов.

Алгол, используемый в B5000, представляет собой расширенное подмножество АЛГОЛОВ. Он включает мощные инструкции по манипулированию строками, но исключает определенные конструкции ALGOL, в частности, неопределенные формальные параметры. Механизм DEFINE служит той же цели, что и #defines найден в C, но полностью интегрирован в язык, а не является препроцессором. Тип данных EVENT облегчает координацию между процессами, а блоки ON FAULT позволяют обрабатывать программные ошибки.

Пользовательский уровень ALGOL не включает многие небезопасные конструкции, необходимые для операционной системы и другого системного программного обеспечения. Два уровня языковых расширений предоставляют дополнительные конструкции: ESPOL и NEWP для написания MCP и тесно связанного программного обеспечения, а также DCALGOL и DMALGOL для предоставления более конкретных расширений для определенных видов системного программного обеспечения.

ESPOL и NEWP

Первоначально операционная система B5000 MCP была написана как расширение расширенного АЛГОЛА под названием ESPOL (Язык, ориентированный на программирование исполнительных систем). Он был заменен в середине-конце 70-х на язык под названием NEWP. Хотя NEWP, вероятно, означало просто «Новый язык программирования», название окружено легендами. Распространенная (возможно, апокрифическая) история в Берроуза в то время предполагала, что это произошло от «Отсутствие привилегий на использование ванных комнат для руководителей. » Другая история заключается в том, что примерно в 1976 году Джон МакКлинток из Берроуза (инженер-программист, разрабатывающий NEWP) назвал язык «NEWP» после того, как его снова спросили, «есть ли у него имя еще?»: Ответив «nyoooop», он принял это как имя. NEWP тоже был подмножеством расширений ALGOL, но он был более безопасным, чем ESPOL, и отбрасывал некоторые малоиспользуемые сложности ALGOL. Фактически, все небезопасные конструкции отклоняются компилятором NEWP, если только блок не помечен специально для выполнения этих инструкций. Такая маркировка блоков обеспечивает многоуровневый механизм защиты.

Программы NEWP, содержащие небезопасные конструкции, изначально не исполняются. Администратор безопасности системы может «благословить» такие программы и сделать их исполняемыми, но обычные пользователи не могут этого сделать. (Даже «привилегированные пользователи», которые обычно имеют в основном права root, могут быть не в состоянии сделать это в зависимости от конфигурации, выбранной сайтом.) Хотя NEWP можно использовать для написания общих программ и имеет ряд функций, предназначенных для крупных программных проектов. , он не поддерживает все, что делает ALGOL.

NEWP имеет ряд средств для реализации крупномасштабных программных проектов, таких как операционная система, включая именованные интерфейсы (функции и данные), группы интерфейсов, модули и супермодули. Модули группируют данные и функции вместе, обеспечивая легкий доступ к данным как к глобальным внутри модуля. Интерфейсы позволяют модулю импортировать и экспортировать функции и данные. Супермодули позволяют группировать модули.

DCALGOL и системы управления сообщениями (MCS)

Второй промежуточный уровень безопасности между кодом операционной системы (в NEWP) и пользовательскими программами (в ALGOL) предназначен для промежуточное ПО программы, написанные на DCALGOL (data comms ALGOL). Это используется для приема и отправки сообщений, которые удаляют сообщения из входных очередей и помещают их в очереди для обработки другими процессами в системе. Промежуточное ПО, такое как COMS (появившееся около 1984 г.), получает сообщения по сети и отправляет эти сообщения в определенные процессы обработки или в MCS (систему управления сообщениями), такую ​​как CANDE ("Cприказ И Edit, "среда разработки программы").

MCS - это элементы программного обеспечения, которые стоит отметить: они управляют пользовательскими сеансами и обеспечивают отслеживание состояния пользователя без необходимости запускать процессы для каждого пользователя, поскольку один стек MCS может использоваться многими пользователями. Балансировка нагрузки также может быть достигнута на уровне MCS. Например, заявив, что вы хотите обрабатывать 30 пользователей в стеке, и в этом случае, если у вас есть от 31 до 60 пользователей, у вас есть два стека, от 61 до 90 пользователей, три стека и т. Д. Это дает машинам B5000 большое преимущество в производительности в server, поскольку вам не нужно запускать другой пользовательский процесс и, таким образом, создавать новый стек каждый раз, когда пользователь подключается к системе. Таким образом, вы можете эффективно обслуживать пользователей (независимо от того, требуется ли им состояние или нет) с помощью MCS. MCS также являются основой крупномасштабной обработки транзакций.

MCS разговаривал с внешним сопроцессором, DCP (Datacomm Control Processor). Это был 24-битный миникомпьютер с традиционной архитектурой регистров и возможностью аппаратного ввода-вывода для обработки тысяч удаленных терминалов. DCP и B6500 обменивались сообщениями в памяти, по сути, пакетами в сегодняшних терминах, а MCS выполняла обработку этих сообщений на стороне B6500. В первые годы у DCP был ассемблер (Dacoma), прикладная программа под названием DCPProgen, написанная на B6500 ALGOL. Позже NDL Компилятор (Network Definition Language) сгенерировал код DCP и NDF (файл определения сети). Для каждого вида инструкций DCP существовала одна функция АЛГОЛА, и если вы вызываете эту функцию, соответствующие биты инструкции DCP будут отправлены на выход. Программа DCP была программой АЛГОЛА, содержащей только длинный список вызовов этих функций, по одному для каждого оператора языка ассемблера. По сути, ALGOL действовал как проход макроса макроассемблера. Первым проходом был компилятор ALGOL; второй проход запускал результирующую программу (на B6500), которая затем выдавала двоичный файл для DCP.

ДМАЛГОЛ и базы данных

Другой вариант АЛГОЛА - DMALGOL (АЛГОЛ управления данными). DMALGOL - это АЛГОЛ, расширенный для компиляции программного обеспечения базы данных DMSII из файлов описания базы данных, созданных компилятором DASDL (Data Access and Structure Definition Language). Разработчики и администраторы баз данных собирают описания баз данных для создания кода DMALGOL, адаптированного для указанных таблиц и индексов. Администраторам никогда не нужно писать DMALGOL самостоятельно. Обычные программы пользовательского уровня получают доступ к базе данных с помощью кода, написанного на языках приложений, в основном ALGOL и COBOL, дополненных инструкциями базы данных и директивами обработки транзакций. Самая примечательная особенность DMALGOL - это механизмы предварительной обработки для генерации кода для обработки таблиц и индексов.

Предварительная обработка DMALGOL включает переменные и циклы и может генерировать имена на основе переменных времени компиляции. Это позволяет адаптировать гораздо больше, чем может быть сделано средствами предварительной обработки, в которых отсутствуют циклы.

DMALGOL используется для предоставления специализированных процедур доступа для DMSII базы данных. После того как база данных определена с использованием языка определения структуры и доступа к данным (DASDL), схема преобразуется препроцессором в специализированные процедуры доступа DMALGOL, а затем компилируется. Это означает, что, в отличие от других реализаций СУБД, часто нет необходимости в базе данных. -специфический код if / then / else во время выполнения. В 1970-х такая «адаптация» очень широко использовалась для уменьшения объема кода и времени выполнения. В последующие годы он стал гораздо реже использоваться, отчасти потому, что тонкая настройка памяти и скорости на низком уровне стала менее критичной, а отчасти потому, что устранение предварительной обработки упростило кодирование и, таким образом, позволило сделать более важные оптимизации. DMALGOL включал глаголы типа «найти», «заблокировать», «хранить». Также были включены глаголы «beginintransaction» и «endtransaction», решающие ситуацию тупика, когда несколько процессов обращались и обновляли одни и те же структуры.

Рой Гак из Берроуза был одним из основных разработчиков DMSII.

В более поздние годы, когда размер кода компилятора стал менее важной проблемой, большинство конструкций предварительной обработки стали доступны на пользовательском уровне ALGOL. Только небезопасные конструкции и прямая обработка файла описания базы данных остаются ограниченными DMALGOL.

Архитектура стека

Во многих ранних системах и языках программистам часто говорили не делать свои подпрограммы слишком маленькими. Вызов и возврат процедур были дорогостоящими, потому что для обслуживания стека приходилось выполнять ряд операций. B5000 был разработан как стековая машина - все программные данные, за исключением массивов (которые включают строки и объекты), хранились в стеке. Это означало, что операции со стеком были оптимизированы для повышения эффективности. В стек-ориентированной машине нет регистров, адресуемых программистом.

Многозадачность также очень эффективен на линиях B5000 и B6500. Есть специальная инструкция по переключению процесса:

B5000, B5500, B5700

Инициировать P1 (IP1) и инициировать P2 (IP2)^[5]:6–30

B6500, B7500 и преемники

MVST (переместить стек).^{[7]:8–19[19]}

Каждый стек и связанный^{[NB 5]} Справочная таблица программ (PRT) представляет процесс (задачу или поток), и задачи могут быть заблокированы в ожидании запросов ресурсов (включая ожидание запуска процессора, если задача была прервана из-за вытесняющей многозадачности). Пользовательские программы не могут выдавать IP1,^{[NB 5]} IP2^{[NB 5]} или МВСТ,^{[NB 6]} и есть только одно место в операционной системе, где это делается.

Таким образом, переключение процесса происходит примерно так: процесс запрашивает ресурс, который не доступен немедленно, возможно, чтение записи файла из блока, которого в данный момент нет в памяти, или системный таймер вызвал прерывание. Код операционной системы вводится и запускается поверх пользовательского стека. Он отключает таймеры пользовательского процесса. Текущий процесс помещается в соответствующую очередь для запрашиваемого ресурса или в очередь готовности, ожидающую процессора, если это вытесняющее переключение контекста. Операционная система определяет первый процесс в очереди готовности и вызывает инструкцию move_stack, которая делает активным процесс во главе очереди готовности.

Скорость и производительность стека

Некоторые противники архитектуры B5000 считали, что стековая архитектура изначально медленная по сравнению с архитектурой на основе регистров. Уловка скорости системы заключается в том, чтобы хранить данные как можно ближе к процессору. В стеке B5000 это было сделано путем назначения двух верхних позиций стека двум регистрам A и B. Большинство операций выполняется с этими двумя верхними позициями стека. На более быстрых машинах, предшествующих B5000, большая часть стека может храниться в регистрах или кэше рядом с процессором.

Таким образом, разработчики нынешних преемников систем B5000 могут оптимизировать любые новейшие технологии, и программистам не нужно корректировать свой код, чтобы он работал быстрее - им даже не нужно перекомпилировать, что защищает инвестиции в программное обеспечение. Некоторые программы, как известно, запускаются в течение многих лет после многих обновлений процессора. Такое ускорение ограничено на регистровых машинах.^{[нужна цитата]}

Еще один аргумент в пользу скорости, предложенный разработчиками RISC, заключался в том, что скорость процессора значительно выше, если все находится на одном кристалле. Это был актуальный момент в 1970-х годах, когда более сложные архитектуры, такие как B5000, требовали слишком большого количества транзисторов для размещения на одном кристалле. Однако сегодня это не так, и каждая последующая машина B5000 теперь умещается на одном чипе, а также поддерживает такие методы поддержки производительности, как кэширование и конвейеры команд.

Фактически, линейка преемников B5000 серии A включала первый однокристальный мэйнфрейм Micro-A конца 1980-х годов. Этот «мэйнфрейм» (названный SCAMP от Single-Chip A-series Mainframe Processor) установлен на подключаемой плате ПК на базе Intel.

Как программы отображаются в стек

Вот пример того, как программы отображаются на структуру стека.

начинать   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Это лексический уровень 2 (нулевой уровень зарезервирован для операционной системы, а уровень 1 - для сегментов кода). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - На уровне 2 мы размещаем глобальные переменные для нашей программы. целое число я, j, k;   настоящий ж, грамм;   множество а [0:9];      процедура п (настоящий p1, p2);      ценить p1; - p1 передается по значению, p2 неявно передается по ссылке. начинать         - - - - - - - - - - - - - - - - - - - Этот блок находится на лексическом уровне 3 - - - - - - - - - - - - - - - - - - настоящий r1, r2;
         r2 := p1 * 5;         p2 := r2; - Это наборы грамм к стоимости r2         p1 := r2; - Это наборы p1 к r2, но нет ж         - Поскольку это перезаписывает исходное значение ж в p1 Это мог бы быть ошибкой кодирования. Поэтому некоторые из последователей ALGOL настаивают на том, чтобы параметры-значения были доступны только для чтения, но большинство этого не делает. если r2 > 10 тогда            начинать               - - - - - - - - - - - - - - - - - - - - - - - - - - - - Переменная, объявленная здесь, делает этот лексический уровень 4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - целое число п;
               - Объявление переменной делает это блоком, который будет вызывать некоторый код построения стека. Обычно здесь не объявляются переменные, и в этом случае - это будет составной оператор, а не блок. ... <== образец стека выполняется где-то здесь. конец;      конец;         .....      п (ж, грамм);конец.

Каждый кадр стека соответствует лексическому уровню в текущей среде выполнения. Как видите, лексический уровень - это статическая текстовая вложенность программы, а не динамическая вложенность вызовов. Правила видимости ALGOL, языка, разработанного для однопроходных компиляторов, означают, что в этой части кода видны только переменные, объявленные перед текущей позицией, поэтому требуется предварительное объявление. Все переменные, объявленные во включающих блоках, видны. Другой случай состоит в том, что переменные с тем же именем могут быть объявлены во внутренних блоках, и они эффективно скрывают внешние переменные, которые становятся недоступными.

Лексическая вложенность статична, не связана с вложенностью выполнения с рекурсией и т. Д., Поэтому очень редко можно найти процедуру, вложенную более чем на пять уровней в глубину, и можно утверждать, что такие программы будут плохо структурированы. Машины B5000 позволяют размещать до 32 уровней. Это могло вызвать затруднения для некоторых систем, которые генерировали исходный код Algol в качестве вывода (адаптированный для решения некоторой специальной проблемы), если метод генерации часто вложил процедуру в процедуру.

Процедуры

Процедуры могут быть вызваны четырьмя способами - обычным, вызовом, обработкой и запуском.

Обычный вызов вызывает процедуру обычным способом, которым любой язык вызывает подпрограмму, путем приостановки вызывающей подпрограммы до тех пор, пока вызванная процедура не вернется.

В вызов механизм вызывает процедуру как сопрограмму. У сопрограмм есть партнерские задачи, в которых управление явно передается между задачами с помощью инструкции CONTINUE. Это синхронные процессы.

В процесс mechanism invokes a procedure as an asynchronous task and in this case a separate stack is set up starting at the lexical level of the processed procedure. As an asynchronous task, there is no control over exactly when control will be passed between the tasks, unlike coroutines. The processed procedure still has access to the enclosing environment and this is a very efficient IPC (Inter Process Communication) mechanism. Since two or more tasks now have access to common variables, the tasks must be synchronized to prevent race conditions, which is handled by the EVENT data type, where processes can WAIT on an event until they are caused by another cooperating process. EVENTs also allow for mutual exclusion synchronization through the PROCURE and LIBERATE functions. If for any reason the child task dies, the calling task can continue – however, if the parent process dies, then all child processes are automatically terminated. On a machine with more than one processor, the processes may run simultaneously. This EVENT mechanism is a basic enabler for multiprocessing in addition to multitasking.

Run invocation type

The last invocation type is run. This runs a procedure as an independent task which can continue on after the originating process terminates. For this reason, the child process cannot access variables in the parent's environment, and all parameters passed to the invoked procedure must be call-by-value.

Thus Burroughs Extended ALGOL had some of the multi-processing and synchronization features of later languages like Ада. It made use of the support for asynchronous processes that was built into the hardware.

Inline procedures

One last possibility is that a procedure may be declared INLINE, that is when the compiler sees a reference to it the code for the procedure is generated inline to save the overhead of a procedure call; this is best done for small pieces of code. Inline functions are similar to parameterized macros Такие как C #defines, except you don't get the problems with parameters that you can with macros. This facility is available in NEWP.

Asynchronous calls

In the example program only normal calls are used, so all the information will be on a single stack. For asynchronous calls, the stack would be split into multiple stacks so that the processes share data but run asynchronously.

Display registers

A stack hardware optimization is the provision of D (or "display") registers. These are registers that point to the start of each called stack frame. These registers are updated automatically as procedures are entered and exited and are not accessible by any software. There are 32 D registers, which is what limits to 32 levels of lexical nesting.

Consider how we would access a lexical level 2 (D[2]) global variable from lexical level 5 (D[5]). Suppose the variable is 6 words away from the base of lexical level 2. It is thus represented by the address couple (2, 6). If we don't have D registers, we have to look at the control word at the base of the D[5] frame, which points to the frame containing the D[4] environment. We then look at the control word at the base of this environment to find the D[3] environment, and continue in this fashion until we have followed all the links back to the required lexical level. This is not the same path as the return path back through the procedures which have been called in order to get to this point. (The architecture keeps both the data stack and the call stack in the same structure, but uses control words to tell them apart.)

As you can see, this is quite inefficient just to access a variable. With D registers, the D[2] register points at the base of the lexical level 2 environment, and all we need to do to generate the address of the variable is to add its offset from the stack frame base to the frame base address in the D register. (There is an efficient linked list search operator LLLU, which could search the stack in the above fashion, but the D register approach is still going to be faster.) With D registers, access to entities in outer and global environments is just as efficient as local variable access.

D Tag Data                — Address couple, Commentsregister

| 0        | п          | (4, 1) The integer п (declared on entry to a block, not a procedure)|-----------------------|| D[4]==>3 | MSCW       | (4, 0) The Mark Stack Control Word containing the link to D[3].|=======================|| 0        | r2         | (3, 5) The real r2|-----------------------|| 0        | r1         | (3, 4) The real r1|-----------------------|| 1        | p2         | (3, 3) A SIRW reference to грамм at (2,6)|-----------------------|| 0        | p1         | (3, 2) The parameter p1 from value of ж |-----------------------|| 3        | RCW        | (3, 1) A return control word|-----------------------|| D[3]==>3 | MSCW       | (3, 0) The Mark Stack Control Word containing the link to D[2].|=======================|| 1        | а          | (2, 7) The array а  ======>[ten word memory block]|-----------------------|| 0        | грамм          | (2, 6) The real грамм |-----------------------|| 0        | ж          | (2, 5) The real ж |-----------------------|| 0        | k          | (2, 4) The integer k |-----------------------|| 0        | j          | (2, 3) The integer j |-----------------------|| 0        | я          | (2, 2) The integer я|-----------------------|| 3        | RCW        | (2, 1) A return control word|-----------------------|| D[2]==>3 | MSCW       | (2, 0) The Mark Stack Control Word containing the link to the previous stack frame.|=======================| — Stack bottom

If we had invoked the procedure p as a coroutine, or a process instruction, the D[3] environment would have become a separate D[3]-based stack. This means that asynchronous processes still have access to the D[2] environment as implied in ALGOL program code. Taking this one step further, a totally different program could call another program’s code, creating a D[3] stack frame pointing to another process’ D[2] environment on top of its own process stack. At an instant the whole address space from the code’s execution environment changes, making the D[2] environment on the own process stack not directly addressable and instead make the D[2] environment in another process stack directly addressable. This is how library calls are implemented. At such a cross-stack call, the calling code and called code could even originate from programs written in different source languages and be compiled by different compilers.

The D[1] and D[0] environments do not occur in the current process's stack. The D[1] environment is the code segment dictionary, which is shared by all processes running the same code. The D[0] environment represents entities exported by the operating system.

Stack frames actually don’t even have to exist in a process stack. This feature was used early on for file I/O optimization, the FIB (file information block) was linked into the display registers at D[1] during I/O operations. In the early nineties, this ability was implemented as a language feature as STRUCTURE BLOCKs and – combined with library technology - as CONNECTION BLOCKs. The ability to link a data structure into the display register address scope implemented object orientation. Thus, the B5000 actually used a form of object orientation long before the term was ever used.

On other systems, the compiler might build its symbol table in a similar manner, but eventually the storage requirements would be collated and the machine code would be written to use flat memory addresses of 16-bits or 32-bits or even 64-bits. These addresses might contain anything so that a write to the wrong address could damage anything. Instead, the two-part address scheme was implemented by the hardware. At each lexical level, variables were placed at displacements up from the base of the level's stack, typically occupying one word - double precision or complex variables would occupy two. Arrays were нет stored in this area, only a one word descriptor for the array. Thus, at each lexical level the total storage requirement was not great: dozens, hundreds or a few thousand in extreme cases, certainly not a count requiring 32-bits or more. And indeed, this was reflected in the form of the VALC instruction (value call) that loaded an operand onto the stack. This op-code was two bits long and the rest of the byte's bits were concatenated with the following byte to give a fourteen-bit addressing field. The code being executed would be at some lexical level, say six: this meant that only lexical levels zero to six were valid, and so just three bits were needed to specify the lexical level desired. The address part of the VALC operation thus reserved just three bits for that purpose, with the remainder being available for referring to entities at that and lower levels. A deeply nested procedure (thus at a high lexical level) would have fewer bits available to identify entities, and so for level sixteen upwards their number was restricted. At the deepest nesting five bits would be needed to specify the choice of levels 0–31 thus leaving nine bits to identify 512 entities - not a severe constraint. This is much more compact than addressing entities by their literal memory address in a 32-bit addressing space. Further, only the VALC opcode loaded data: opcodes for ADD, MULT and so forth did no addressing, working entirely on the top elements of the stack.

Much more important is that this method meant that many errors available to systems employing flat addressing could not occur because they were simply unspeakable even at the machine code level. A task had no way to corrupt memory in use by another task, because it had no way to develop its address. Similarly, within a task, an array descriptor contained information on the array's bounds, and so any indexing operation was checked by the hardware: put another way, each array formed its own address space. In any case, the tagging of all memory words provided a second level of protection: a misdirected assignment of a value could only go to a data-holding location, not to one holding a pointer or an array descriptor, etc. and certainly not to a location holding machine code.

Array storage

Arrays were not stored contiguous in memory with other variables, they were each granted their own address space, which was located via the descriptor. The access mechanism was to calculate on the stack the index variable (which therefore had the full integer range potential, not just fourteen bits) and use it as the offset into the array's address space, with bound checking provided by the hardware. Should an array's length exceed 1,024 words, the array would be segmented, and the index be converted into a segment index and an offset into the indexed segment. In ALGOL's case, a multidimensional array would employ multiple levels of such addressing. For a reference to A(i,j), the first index would be into an array of descriptors, one descriptor for each of the rows of A, which row would then be indexed with j as for a single-dimensional array, and so on for higher dimensions. Hardware checking against the known bounds of all the array's indices would prevent erroneous indexing.

FORTRAN however regards all multidimensional arrays as being equivalent to a single-dimensional array of the same size, and for a multidimensional array simple integer arithmetic is used to calculate the offset where element A(i,j,k) would be found in that single sequence. The single-dimensional equivalent array, possibly segmented if large enough, would then be accessed in the same manner as a single-dimensional array in ALGOL. Although accessing outside this array would be prevented, a wrong value for one index combined with a suitably wrong value for another index might not result in a bounds violation of the single sequence array; in other words, the indices were not checked individually.

Because an array's storage was not bounded on each side by storage for other items, it was easy for the system to "resize" an array - though changing the number of dimensions was precluded because compilers required all references to have the same number of dimensions. In ALGOL's case, this enabled the development of "ragged" arrays, rather than the usual fixed rectangular (or higher dimension) arrays. Thus in two dimensions, a ragged array would have rows that were of different sizes. For instance, given a large array A(100,100) of mostly-zero values, a sparse array representation that was declared as SA(100,0) could have each row resized to have exactly enough elements to hold only the non-zero values of A along that row.

Because arrays larger than 1024 words were segmented but smaller arrays were not, on a system that was short of real memory, increasing the declared size of a collection of scratchpad arrays from 1,000 to say 1,050 could mean that the program would run with far less "thrashing" as only the smaller individual segments in use were needed in memory. Actual storage for an array segment would be allocated at run time only if an element in that segment were accessed, and all elements of a created segment would be initialised to zero. Not initialising an array to zero at the start therefore was encouraged by this, normally an unwise omission.

Stack structure advantages

One nice thing about the stack structure is that if a program does happen to fail, a stack dump is taken and it is very easy for a programmer to find out exactly what the state of a running program was. Compare that to core dumps and exchange packages of other systems.

Another thing about the stack structure is that programs are implicitly recursive. FORTRAN was not expected to support recursion and perhaps one stumbling block to people's understanding of how ALGOL was to be implemented was how to implement recursion. On the B5000, this was not a problem – in fact, they had the reverse problem, how to stop programs from being recursive. In the end they didn't bother. The Burroughs FORTRAN compiler allowed recursive calls (just as every other FORTRAN compiler does), but unlike many other computers, on a stack-based system the returns from such calls succeeded as well. This could have odd effects, as with a system for the formal manipulation of mathematical expressions whose central subroutines repeatedly invoked each other without ever returning: large jobs were ended by stack overflow!

Thus Burroughs FORTRAN had better error checking than other contemporary implementation of FORTRAN.^{[нужна цитата]} For instance, for subroutines and functions it checked that they were invoked with the correct number of parameters, as is normal for ALGOL-style compilers. On other computers, such mismatches were common causes of crashes. Similarly with the array-bound checking: programs that had been used for years on other systems embarrassingly often would fail when run on a Burroughs system. In fact, Burroughs became known for its superior compilers and implementation of languages, including the object-oriented Simula (a superset of ALGOL), and Iverson, the designer of APL declared that the Burroughs implementation of APL was the best he'd seen.^{[нужна цитата]} John McCarthy, the language designer of LISP disagreed, since LISP was based on modifiable code^{[нужна цитата]}, he did not like the unmodifiable code of the B5000^{[нужна цитата]}, but most LISP implementations would run in an interpretive environment anyway.

The storage required for the multiple processes came from the system's memory pool as needed. There was no need to do SYSGENs on Burroughs systems as with competing systems in order to preconfigure memory partitions in which to run tasks.

Tagged architecture

The most defining aspect of the B5000 is that it is a stack machine as treated above. However, two other very important features of the architecture is that it is tag-based and descriptor-based.

In the original B5000, a flag bit in each control or numeric word^{[NB 7]} was set aside to identify the word as a control word or numeric word. This was partially a security mechanism to stop programs from being able to corrupt control words on the stack.

Later, when the B6500 was designed, it was realized that the 1-bit control word/numeric distinction was a powerful idea and this was extended to three bits outside of the 48 bit word into a tag. The data bits are bits 0–47 and the tag is in bits 48–50. Bit 48 was the read-only bit, thus odd tags indicated control words that could not be written by a user-level program. Code words were given tag 3. Here is a list of the tags and their function:

Internally, some of the machines had 60 bit words, with the extra bits being used for engineering purposes such as a Hamming code error-correction field, but these were never seen by programmers.

The current incarnation of these machines, the Unisys ClearPath has extended tags further into a four bit tag. The microcode level that specified four bit tags was referred to as level Gamma.

Even-tagged words are user data which can be modified by a user program as user state. Odd-tagged words are created and used directly by the hardware and represent a program's execution state. Since these words are created and consumed by specific instructions or the hardware, the exact format of these words can change between hardware implementation and user programs do not need to be recompiled, since the same code stream will produce the same results, even though system word format may have changed.

Tag 1 words represent on-stack data addresses. The normal IRW simply stores an address couple to data on the current stack. The SIRW references data on any stack by including a stack number in the address.

Tag 5 words are descriptors, which are more fully described in the next section. Tag 5 words represent off-stack data addresses.

Tag 7 is the program control word which describes a procedure entry point. When operators hit a PCW, the procedure is entered. The ENTR operator explicitly enters a procedure (non-value-returning routine). Functions (value-returning routines) are implicitly entered by operators such as value call (VALC). Global routines are stored in the D[2] environment as SIRWs that point to a PCW stored in the code segment dictionary in the D[1] environment. The D[1] environment is not stored on the current stack because it can be referenced by all processes sharing this code. Thus code is reentrant and shared.

Tag 3 represents code words themselves, which won't occur on the stack. Tag 3 is also used for the stack control words MSCW, RCW, TOSCW.

Figure 9.2 From the ACM Monograph in the References. Elliot Organick 1973.

Descriptor-based architecture

The figure to the left shows how the Burroughs Large System architecture was fundamentally a hardware architecture for object-oriented programming, something that still doesn't exist in conventional architectures.

Наборы инструкций

There are three distinct instruction sets for the Burroughs large systems. All three are based on short syllables that fit evenly into words.

B5000, B5500 and B5700

Programs on a B5000, B5500 and B5700 are made up of 12-bit syllables, four to a word. The architecture has two modes, Word Mode and Character Mode, and each has a separate repertoire of syllables. A processor may be either Control State or Normal State, and certain syllables are only permissible in Control State. The architecture does not provide for addressing registers or storage directly; all references are through the 1024 word Program Reference Table, current code segment, marked locations within the stack or to the A and B registers holding the top two locations on the stack. Burroughs numbers bits in a syllable from 0 (high bit) to 11 (low bit)

B6500, B7500 and successors

Programs are made up of 8-bit syllables, which may be Name Call, be Value Call or form an operator, which may be from one to twelve syllables in length. There are less than 200 операторы, all of which fit into 8-bit syllables. Many of these operators are polymorphic depending on the kind of data being acted on as given by the tag. If we ignore the powerful string scanning, transfer, and edit operators, the basic set is only about 120 operators. If we remove the operators reserved for the operating system such as MVST and HALT, the set of operators commonly used by user-level programs is less than 100. The Name Call and Value Call syllables contain address couples; the Operator syllables either use no addresses or use control words and descriptors on the stack.

Multiple processors

The B5000 line also were pioneers in having multiple processors connected together on a high-speed bus. The B7000 line could have up to eight processors, as long as at least one was an I/O module. RDLK is a very low-level way of synchronizing between processors. The high level used by user programs is the EVENT data type. The EVENT data type did have some system overhead. To avoid this overhead, a special locking technique called Dahm locks (named after a Burroughs software guru, Dave Dahm) can be used.

Notable operators are:

HEYU — send an interrupt to another processor
RDLK — Low-level semaphore operator: Load the A register with the memory location given by the A register and place the value in the B register at that memory location in a single uninterruptible cycle. The Algol compiler produced code to invoke this operator via a special function that enabled a "swap" operation on single-word data without an explicit temporary value. x:=RDLK(x,y);
WHOI — Processor identification
IDLE — Idle until an interrupt is received

Two processors could infrequently simultaneously send each other a 'HEYU' command resulting in a lockup known as 'a deadly embrace'.

Influence of the B5000

The direct influence of the B5000 can be seen in the current Unisys ClearPath range of mainframes which are the direct descendants of the B5000 and still have the MCP operating system after 40 years of consistent development. This architecture is now called emode (for emulation mode) since the B5000 architecture has been implemented on machines built from Intel Xeon processors running the x86 instruction set as the native instruction set, with code running on those processors emulating the B5000 instruction set. In those machines, there was also going to be an nmode (native mode), but this was dropped^{[нужна цитата]}, so you may often hear the B5000 successor machines being referred to as "emode machines".

B5000 machines were programmed exclusively in high-level languages; there is no assembler.

The B5000 stack architecture inspired Chuck Moore, the designer of the programming language Forth, who encountered the B5500 while at MIT. В Forth - The Early Years, Moore described the influence, noting that Forth's DUP, DROP and SWAP came from the corresponding B5500 instructions (DUPL, DLET, EXCH).

B5000 machines with their stack-based architecture and tagged memory also heavily influenced the Soviet Elbrus series of mainframes and суперкомпьютеры. The first two generations of the series featured tagged memory and stack-based CPUs that were programmed only in high-level languages. There existed a kind of an язык ассемблера for them, called El-76, but it was more or less a modification of ALGOL 68 and supported structured programming and first-class procedures. Later generations of the series, though, switched away from this architecture to the ЭПИЧЕСКИЙ-подобно VLIW CPUs.

В Hewlett Packard designers of the HP 3000 business system had used a B5500 and were greatly impressed by its hardware and software; they aimed to build a 16-bit minicomputer with similar software. Several other HP divisions created similar minicomputer or microprocessor stack machines. Bob Barton's work on reverse Polish notation (RPN) also found its way into HP calculators beginning with the 9100A, and notably the HP-35 and subsequent calculators.

The NonStop systems designed by Tandem Computers in the late 1970s and early 1980s were also 16-bit stack machines, influenced by the B5000 indirectly through the HP 3000 connection, as several of the early Tandem engineers were formerly with HP. Around 1990, these systems migrated to MIPS RISC architecture but continued to support execution of stack machine binaries by object code translation or direct emulation. Sometime after 2000, these systems migrated to Itanium architecture and continued to run the legacy stack machine binaries.

Bob Barton was also very influential on Alan Kay. Kay was also impressed by the data-driven tagged architecture of the B5000 and this influenced his thinking in his developments in object-oriented programming and Smalltalk.^{[нужна цитата]}

Another facet of the B5000 architecture was that it was a secure architecture that runs directly on hardware. This technique has descendants in the virtual machines of today^{[нужна цитата]} in their attempts to provide secure environments. One notable such product is the Java JVM which provides a secure sandbox in which applications run.

The value of the hardware-architecture binding that existed before emode would be substantially preserved in the x86-based machines to the extent that MCP was the one and only control program, but the support provided by those machines is still inferior to that provided on the machines where the B5000 instruction set is the native instruction set. A little-known Intel processor architecture that actually preceded 32-bit implementations of the x86 instruction set, the Intel iAPX 432, would have provided an equivalent physical basis, as it too was essentially an object-oriented architecture.

Смотрите также

• Burroughs Medium Systems
• Burroughs Small Systems
• CANDE
• Network Definition Language (NDL)
• Work Flow Language (WFL)
• Octal floating point

Примечания

Рекомендации

Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: "Burroughs large systems" – Новости · газеты · книги · ученый · JSTOR (Ноябрь 2009 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

• The Extended ALGOL Primer (Three Volumes), Donald J. Gregory.
• Computer Architecture: A Structured Approach, R. Doran, Academic Press (1979).
• Stack Computers: The New Wave, Philip J. Koopman, available at: [1]
• B5500, B6500, B6700, B6800, B6900, B7700 manuals at: bitsavers.org

дальнейшее чтение

• Barton, Robert S. "A New Approach to the Functional Design of a Digital Computer" Proceedings of the Western Joint Computer Conference. ACM (1961).
• Burroughs B 5000 Oral history, Charles Babbage Institute, University of Minnesota. The Burroughs 5000 computer series is discussed by individuals responsible for its development and marketing from 1957 through the 1960s in a 1985 conference sponsored by AFIPS и Burroughs Corporation.
• Gray, George (March 1999). "Some Burroughs Transistor Computers". Unisys History Newsletter. 3 (1). Архивировано из оригинал on October 1, 2016.
• Gray, George (October 1999). "Burroughs Third-Generation Computers". Unisys History Newsletter. 3 (5). Архивировано из оригинал on September 26, 2017.
• Hauck, E.A., Dent, Ben A. "Burroughs B6500/B7500 Stack Mechanism", SJCC (1968) pp. 245–251.
• McKeeman, William M. "Language Directed Computer Design", Fall Joint Computer Conference, (1967) pp. 413–417.
• Organick, Elliot I. "Computer System Organization The B5700/B6700 series", Academic Press (1973).
• Waychoff, Richard, "Stories of the B5000 and People Who Were There", September 27, 1979. [2]
• Allweiss, Jack. "The Burroughs B5900 and E-Mode A bridge to 21st Century Computing", Revised 2010.
• Martin, Ian. "'Too far ahead of its time': Britain, Burroughs and real-time banking in the 1960s", Society for the History of Technology Annual Meeting, 20 Sep-3 Oct 2010, Tacoma, USA.

внешняя ссылка

• Ian Joyner's Burroughs page
• The Burroughs B5900 and E-Mode: A bridge to 21st Century Computing - Jack Allweiss
• (web archive of:) Ralph Klimek on the B7800 at Monash University
• "Early Burroughs Machines", Университет Вирджинии's Computer Museum.
• "Computer System Organization", ACM Monograph Series.
• Index of B8500 manuals
• B5500 Emulation Project Project to create a functional emulator for the Burroughs B5500 computer system.
• "Burroughs B6500 film & transcript"