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

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

Burroughs Large Systems Group выпустила семейство большой 48-разрядных ЭВМ с использованием стеки машинных наборов команд с плотными слогами . ^{[NB 1]} Первой машиной в семействе была B5000 в 1961 году. Она была очень хорошо оптимизирована для компиляции программ на ALGOL 60 с использованием однопроходных компиляторов. Он превратился в B5500. Последующие серьезные изменения включают линейку B6500 / B6700 и ее преемников, а также отдельную линейку B8500.

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

Фон [ править ]

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

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

B5000 [ править ]

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

Уникальные особенности [ править ]

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

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

Уникальный дизайн системы [ править ]

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

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

Языковая поддержка [ править ]

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

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

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

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

B6500 и B7500 [ править ]

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

• В B6500 были инструкции переменной длины с 8-битным слогом вместо инструкций фиксированной длины с 12-битным слогом .
• B6500 имел 51-битное ^{[NB 4]} вместо 48-битного слова и использовал 3 бита в качестве тега.
• B6500 имел симметричную многопроцессорность (SMP)
• У B6500 был стек Saguaro
• 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]

История [ править ]

В нижеследующем обсуждении обозначения машин 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. После слияния, в результате которого Burroughs приобрела 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. Офис в округе Ориндж, который располагался на заводе в Мишн-Вьехо, Калифорния, но иногда включал в себя объекты в соседнем Ирвине и Лейк-Форест , отвечал за меньшую линию B6x00, в то время как операции на восточном побережье, базирующиеся в Тредифрине, штат Пенсильвания., обработал большую линию B7x00. Все машины обеих линий были полностью объектно-совместимыми, то есть программа, скомпилированная на одной, могла быть выполнена на другой. В более новых и больших моделях были инструкции, которые не поддерживались на более старых и более медленных моделях, но оборудование при обнаружении нераспознанной инструкции вызывало функцию операционной системы, которая ее интерпретировала. Другие отличия включают в себя то, как выполнялись переключение процессов и ввод / вывод, а также функции обслуживания и холодного запуска. Более крупные системы включали аппаратное планирование процессов и более функциональные модули ввода / вывода и более функциональные процессоры обслуживания. Когда модели Bxx00 были заменены моделями серии A, различия были сохранены, но их уже нельзя было легко идентифицировать по номеру модели.

АЛГОЛ [ править ]

Большие системы Burroughs реализуют стековую архитектуру, основанную на Алголе . B5000 была первой системой на основе стека.

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

Алгол, используемый в B5000, представляет собой расширенное подмножество АЛГОЛОВ. Он включает мощные инструкции по манипулированию строками, но исключает определенные конструкции АЛГОЛА, в частности, неопределенные формальные параметры. Механизм 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 (ALGOL передачи данных). Это используется для приема и отправки сообщений, которые удаляют сообщения из входных очередей и помещают их в очереди для обработки другими процессами в системе. Промежуточное ПО, такое как COMS (появившееся около 1984 г.), принимает сообщения по всей сети и отправляет эти сообщения в определенные процессы обработки или в MCS (систему управления сообщениями), такую ​​как CANDE (« C ommand AND E dit», среда разработки программ).

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. Позже НДЛКомпилятор (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]} или MVST, ^{[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 мы размещаем глобальные переменные для нашей программы.  целое число  i , j , k ; реальные  f , g ; массив  a [0: 9];  процедура  p ( вещественные  p1 , p2 ); значение  p1 ; - p1 передается по значению, p2 неявно передается по ссылке. начинать - - - - - - - - - - - - - - - - - - - Этот блок находится на лексическом уровне 3 - - - - - - - - - - - - - - - - - - вещественные  r1 , r2 ; 
 r2  : = p1 * 5 ; p2  : = r2 ; - Это устанавливает g в значение r2  p1  : = r2 ; - Это устанавливает p1 в r2 , но не f - Поскольку это перезаписывает исходное значение f в p1, это может быть - ошибка кодирования. Поэтому некоторые из последователей Алгола настаивают на том, что - параметры значения доступны только для чтения, но большинство из них - нет.  если  r2 > 10,  то  начинаем - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Объявленная здесь переменная делает этот лексический уровень 4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - целое число  n ;
 - Объявление переменной делает это блоком, который будет вызывать некоторые - код построения стека. Обычно здесь не объявляются переменные, в которых - если это будет составной оператор, а не блок.  ... <== образец стека выполняется где-то здесь. конец ; конец ;  .....  р ( е , ж );конец .

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

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

Процедуры [ править ]

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

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

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

процессмеханизм вызывает процедуру как асинхронную задачу, и в этом случае создается отдельный стек, начиная с лексического уровня обрабатываемой процедуры. В асинхронной задаче нет контроля над тем, когда именно управление будет передаваться между задачами, в отличие от сопрограмм. Обработанная процедура по-прежнему имеет доступ к окружающей среде, и это очень эффективный механизм IPC (Inter Process Communication). Поскольку две или более задач теперь имеют доступ к общим переменным, задачи должны быть синхронизированы, чтобы предотвратить условия гонки, которые обрабатываются типом данных EVENT, где процессы могут ЖДАТЬ события, пока оно не будет вызвано другим взаимодействующим процессом. СОБЫТИЯ также позволяют синхронизировать взаимное исключение с помощью функций PROCURE и LIBERATE. Если по какой-либо причине дочерняя задача умирает, вызывающая задача может продолжаться, однакоесли родительский процесс умирает, все дочерние процессы автоматически завершаются. На машине с более чем одним процессором процессы могут выполняться одновременно. Этот механизм СОБЫТИЯ является основным инструментом для многопроцессорной обработки в дополнение к многозадачности.

Тип запуска [ править ]

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

Таким образом, Burroughs Extended ALGOL обладал некоторыми функциями одновременной обработки и синхронизации более поздних языков, таких как Ada . Он использовал поддержку асинхронных процессов, которая была встроена в оборудование.

Встроенные процедуры [ править ]

Одна последняя возможность состоит в том, что процедура может быть объявлена ​​INLINE, то есть, когда компилятор видит ссылку на нее, код процедуры генерируется встроенным, чтобы сэкономить накладные расходы на вызов процедуры; это лучше всего делать для небольших фрагментов кода. Встроенные функции похожи на параметризованные макросы, такие как C #defines, за исключением того, что вы не получаете проблем с параметрами, которые можно получить с помощью макросов. Эта возможность доступна в NEWP.

Асинхронные вызовы [ править ]

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

Регистры отображения [ править ]

Аппаратная оптимизация стека - это предоставление регистров D (или «отображения»). Это регистры, указывающие на начало каждого вызываемого кадра стека. Эти регистры обновляются автоматически по мере входа в процедуры и выхода из них и недоступны для какого-либо программного обеспечения. Имеется 32 регистра D, что ограничивает 32 уровня лексической вложенности.

Рассмотрим, как мы могли бы получить доступ к глобальной переменной лексического уровня 2 (D [2]) из лексического уровня 5 (D [5]). Предположим, что переменная находится на расстоянии 6 слов от основания лексического уровня 2. Таким образом, она представлена ​​адресной парой (2, 6). Если у нас нет регистров D, мы должны посмотреть на управляющее слово в основании кадра D [5], которое указывает на кадр, содержащий среду D [4]. Затем мы смотрим на контрольное слово в основе этого окружения, чтобы найти окружение D [3], и продолжаем таким же образом, пока не пройдем по всем ссылкам обратно на требуемый лексический уровень. Это не тот же путь, что и обратный путь через процедуры, которые были вызваны, чтобы добраться до этой точки. (Архитектура хранит стек данных и стек вызовов в одной структуре, но использует управляющие слова, чтобы различать их.)

Как видите, просто получить доступ к переменной это неэффективно. С регистрами D регистр D [2] указывает на основу лексической среды уровня 2, и все, что нам нужно сделать для генерации адреса переменной, - это добавить ее смещение от базы кадра стека к базовому адресу кадра в регистр D. (Существует эффективный оператор поиска по связному списку LLLU, который может выполнять поиск в стеке описанным выше способом, но подход с регистром D по-прежнему будет быстрее.) С регистрами D доступ к объектам во внешней и глобальной среде столь же эффективен как доступ к локальной переменной.

D Данные тега - пара адресов, комментариирегистр

| 0 | п | (4, 1) Целое число n (объявленное при входе в блок, а не процедура)| ----------------------- || D [4] ==> 3 | MSCW | (4, 0) Управляющее слово Mark Stack, содержащее ссылку на D [3].| ======================= || 0 | r2 | (3, 5) Действительное r2| ----------------------- || 0 | r1 | (3, 4) Действительное значение r1| ----------------------- || 1 | p2 | (3, 3) Ссылка SIRW на g в (2,6)| ----------------------- || 0 | p1 | (3, 2) Параметр p1 от значения f | ----------------------- || 3 | RCW | (3, 1) Контрольное слово возврата| ----------------------- || D [3] ==> 3 | MSCW | (3, 0) Управляющее слово Mark Stack, содержащее ссылку на D [2].| ======================= || 1 | а | (2, 7) Массив a ======> [блок памяти из десяти слов]| ----------------------- || 0 | г | (2, 6) Действительное g | ----------------------- || 0 | f | (2, 5) Действительное f | ----------------------- || 0 | k | (2, 4) Целое число k | ----------------------- || 0 | j | (2, 3) Целое число j | ----------------------- || 0 | я | (2, 2) Целое число i| ----------------------- || 3 | RCW | (2, 1) Контрольное слово возврата| ----------------------- || D [2] ==> 3 | MSCW | (2, 0) Управляющее слово Mark Stack, содержащее ссылку на предыдущий кадр стека.| ======================= | - дно стека

Если бы мы вызвали процедуру p как сопрограмму или инструкцию процесса, среда D [3] стала бы отдельным стеком на основе D [3]. Это означает, что асинхронные процессы по-прежнему имеют доступ к среде D [2], как это подразумевается в программном коде ALGOL. Сделав еще один шаг, совершенно другая программа могла бы вызывать код другой программы, создавая кадр стека D [3], указывающий на среду D [2] другого процесса поверх своего собственного стека процессов. В один момент все адресное пространство из среды выполнения кода изменяется, делая среду D [2] в собственном стеке процессов не адресуемой напрямую, а вместо этого делает среду D [2] в другом стеке процессов адресуемой напрямую. Так реализованы вызовы библиотеки. При таком вызове кросс-стекавызывающий код и вызываемый код могут даже происходить из программ, написанных на разных исходных языках, и компилироваться разными компиляторами.

Среды D [1] и D [0] не встречаются в стеке текущего процесса. Среда D [1] - это словарь сегментов кода, который используется всеми процессами, выполняющими один и тот же код. Среда D [0] представляет объекты, экспортируемые операционной системой.

Фреймы стека на самом деле даже не должны существовать в стеке процессов. Эта функция изначально использовалась для оптимизации файлового ввода-вывода, FIB (блок информации о файле) был связан с регистрами дисплея в D [1] во время операций ввода-вывода. В начале девяностых эта возможность была реализована как языковая функция как СТРУКТУРНЫЕ БЛОКИ и - в сочетании с библиотечной технологией - как СОЕДИНИТЕЛЬНЫЕ БЛОКИ. Возможность связывать структуру данных с областью адреса отображения регистра реализована ориентацией объекта. Таким образом, B5000 фактически использовал форму объектной ориентации задолго до того, как этот термин вообще был использован.

В других системах компилятор может построить свою таблицу символов аналогичным образом, но в конечном итоге требования к хранилищу будут сопоставлены, и машинный код будет написан с использованием плоских адресов памяти 16-бит, 32-бит или даже 64-бит. Эти адреса могут содержать что угодно, поэтому запись на неправильный адрес может повредить что угодно. Вместо этого двухчастная схема адресации была реализована аппаратно. На каждом лексическом уровне переменные размещались на смещениях вверх от основания стека уровня, обычно занимая одно слово - двойная точность или комплексные переменные занимали бы два. Массивов не былоВ этой области хранится только однословный дескриптор для массива. Таким образом, на каждом лексическом уровне требования к общему объему памяти были невелики: десятки, сотни или несколько тысяч в крайних случаях, конечно, не счет, требующий 32-битных или более. И действительно, это было отражено в форме инструкции VALC (вызов значения), которая загружала операнд в стек. Этот код операции имел длину два бита, а остальные биты байта были объединены со следующим байтом, чтобы получить четырнадцатибитовое поле адресации. Выполняемый код должен быть на каком-то лексическом уровне, скажем, шестом: это означало, что допустимы только лексические уровни от нуля до шести, и поэтому для определения желаемого лексического уровня требовалось всего три бита. Таким образом, адресная часть операции VALC зарезервировала для этой цели всего три бита,остальная часть доступна для ссылки на сущности на этом и более низких уровнях. Глубоко вложенная процедура (таким образом, на высоком лексическом уровне) будет иметь меньше битов, доступных для идентификации сущностей: для уровня с шестнадцатого и выше потребуется пять битов, чтобы указать выбор уровней 0–31, таким образом, оставив девять битов для идентификации не более первого 512 сущностей любого лексического уровня. Это намного компактнее, чем адресация объектов по их буквальному адресу памяти в 32-битном адресном пространстве. Кроме того, данные загружались только кодом операции VALC: коды операций для ADD, MULT и т.д. не выполняли адресацию, работая полностью с верхними элементами стека.для уровня шестнадцатый и выше потребуются пять битов, чтобы указать выбор уровней 0–31, таким образом, оставив девять битов для идентификации не более чем первых 512 объектов любого лексического уровня. Это намного компактнее, чем адресация объектов по их буквальному адресу памяти в 32-битном адресном пространстве. Кроме того, данные загружались только кодом операции VALC: коды операций для ADD, MULT и т.д. не выполняли адресацию, работая полностью с верхними элементами стека.для уровня шестнадцатый и выше потребуется пять битов, чтобы указать выбор уровней 0–31, таким образом, оставив девять битов для идентификации не более чем первых 512 объектов любого лексического уровня. Это намного компактнее, чем адресация объектов по их буквальному адресу памяти в 32-битном адресном пространстве. Кроме того, данные загружались только кодом операции VALC: коды операций для ADD, MULT и т.д. не выполняли адресацию, работая полностью с верхними элементами стека.

Гораздо важнее то, что этот метод означал, что многие ошибки, доступные для систем, использующих плоскую адресацию, не могли произойти, потому что они были просто невыразимы даже на уровне машинного кода. У задачи не было способа повредить память, используемую другой задачей, потому что у нее не было способа разработать свой адрес. Смещения из указанного D-регистра будут проверяться оборудованием относительно границы кадра стека: ложные значения будут захвачены. Точно так же в задаче дескриптор массива содержал информацию о границах массива, и поэтому любая операция индексирования проверялась оборудованием: иными словами, каждый массив формировал свое собственное адресное пространство. В любом случае маркировка всех слов памяти обеспечивала второй уровень защиты: неверно направленное присвоение значения могло попасть только в место хранения данных, а не в место, содержащее указатель или дескриптор массива,и т. д. и, конечно, не в машинный код места хранения.

Хранилище массива [ править ]

Массивы не хранились в памяти непрерывно с другими переменными, каждой из них было предоставлено собственное адресное пространство, которое находилось через дескриптор. Механизм доступа заключался в том, чтобы вычислить в стеке индексную переменную (которая, следовательно, имела потенциал полного целочисленного диапазона, а не только четырнадцать бит) и использовать ее в качестве смещения в адресном пространстве массива с проверкой границ, обеспечиваемой оборудованием. Если длина массива превышает 1024 слова, массив будет сегментирован, и индекс будет преобразован в индекс сегмента, а смещение - в индексированный сегмент. В случае ALGOL многомерный массив будет использовать несколько уровней такой адресации. Для ссылки на A (i, j) первый индекс будет в массиве дескрипторов, по одному дескриптору для каждой строки A,какая строка будет затем проиндексирована j как для одномерного массива, и так далее для более высоких измерений. Аппаратная проверка по известным границам всех индексов массива предотвратит ошибочное индексирование.

Однако FORTRAN рассматривает все многомерные массивы как эквивалентные одномерному массиву того же размера, а для многомерного массива используется простая целочисленная арифметика для вычисления смещения, при котором элемент A (i, j, k) будет найден в этом единственном последовательность. Одномерный эквивалентный массив, возможно, сегментированный, если он достаточно большой, будет доступен таким же образом, как и одномерный массив в ALGOL. Хотя доступ за пределы этого массива будет предотвращен, неправильное значение для одного индекса в сочетании с подходящим образом неправильным значением для другого индекса может не привести к нарушению границ единственного массива последовательностей; Другими словами, индексы не проверялись индивидуально.

Поскольку хранилище массива не было ограничено с каждой стороны хранилищем для других элементов, для системы было легко «изменить размер» массива, хотя изменение количества измерений было исключено, поскольку компиляторы требовали, чтобы все ссылки имели одинаковое количество измерений. В случае с ALGOL это позволило разрабатывать «рваные» массивы, а не обычные фиксированные прямоугольные (или более высокие) массивы. Таким образом, в двух измерениях рваный массив будет иметь строки разного размера. Например, учитывая большой массив A (100,100), состоящий в основном из нулевых значений, в разреженном представлении массива, которое было объявлено как SA (100,0), можно было бы изменить размер каждой строки, чтобы в ней было ровно столько элементов, чтобы содержать только ненулевые значения A вдоль этого ряда.

Поскольку массивы размером более 1024 слов были сегментированы, а массивы меньшего размера - нет, в системе, в которой не хватало реальной памяти, увеличение заявленного размера коллекции массивов блокнотов с 1000 до 1050 могло означать, что программа будет работать с гораздо меньшими " "обмолота", поскольку в памяти требовались только отдельные меньшие по размеру сегменты. Фактическое хранилище для сегмента массива будет выделено во время выполнения только в том случае, если к элементу в этом сегменте будет осуществлен доступ, и все элементы созданного сегмента будут инициализированы нулем. Поэтому отсутствие инициализации массива в ноль в начале поощрялось этим, что обычно является неразумным упущением.

Преимущества структуры стека [ править ]

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

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

Таким образом, Фортран Берроуза имел лучшую проверку ошибок, чем другие современные реализации ФОРТРАНА. ^{[ необходима цитата ]} Например, для подпрограмм и функций он проверял, что они были вызваны с правильным количеством параметров, что является нормальным для компиляторов в стиле ALGOL. На других компьютерах такие несоответствия были частой причиной сбоев. То же самое и с проверкой привязки к массиву: программы, которые годами использовались в других системах, досадно часто терпели неудачу при запуске в системе Берроуза. Фактически, Берроуз стал известен своими превосходными компиляторами и реализацией языков, включая объектно-ориентированную Simula (надмножество ALGOL) и Айверсона , разработчика APL.заявил, что реализация APL Берроуза была лучшей, которую он видел. ^{[ необходима цитата ]} Джон Маккарти , разработчик языка LISP, не согласился, поскольку LISP был основан на модифицируемом коде ^{[ необходима цитата ]} , ему не нравился неизменяемый код B5000 ^{[ необходима цитата ]} , но большинство реализаций LISP работали бы в интерпретируемом среда в любом случае.

Хранилище, необходимое для нескольких процессов, по мере необходимости берется из пула памяти системы. Не было необходимости выполнять SYSGEN в системах Burroughs, как в конкурирующих системах, чтобы предварительно настроить разделы памяти для выполнения задач.

Помеченная архитектура [ править ]

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

В исходном B5000 бит флага в каждом контрольном или числовом слове ^{[NB 7]} был отложен, чтобы идентифицировать слово как контрольное или числовое слово. Частично это был механизм безопасности, чтобы программы не могли повредить управляющие слова в стеке.

Позже, когда был разработан B6500, стало ясно, что различие между 1-битным управляющим словом и числовым значением было мощной идеей, и это было расширено до трех битов вне 48-битного слова в теге. Биты данных - это биты 0–47, а тег - биты 48–50. Бит 48 был битом только для чтения, поэтому нечетные теги указывали управляющие слова, которые не могли быть записаны программой пользовательского уровня. Кодовым словам был присвоен тег 3. Вот список тегов и их функции:

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

Текущая версия этих машин Unisys ClearPath имеет расширенные теги до четырехбитных тегов. Уровень микрокода, который определял четырехбитовые теги, был назван уровнем гаммы.

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

Слова тега 1 представляют адреса данных в стеке. Обычный IRW просто сохраняет пару адресов для данных в текущем стеке. SIRW ссылается на данные в любом стеке, включая номер стека в адрес.

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

Тег 7 - это управляющее слово программы, которое описывает точку входа в процедуру. Когда операторы попадают в PCW, начинается процедура. Оператор ENTR явно входит в процедуру (подпрограмма без возврата значения). Функции (процедуры возврата значения) неявно вводятся операторами, такими как вызов значения (VALC). Глобальные подпрограммы хранятся в среде D [2] как SIRW, которые указывают на PCW, хранящуюся в словаре сегментов кода в среде D [1]. Среда D [1] не сохраняется в текущем стеке, поскольку на нее могут ссылаться все процессы, использующие этот код. Таким образом, код является реентерабельным и совместно используемым.

Тег 3 представляет собой сами кодовые слова, которых не будет в стеке. Тег 3 также используется для слов управления стеком MSCW, RCW, TOSCW.

Архитектура на основе дескрипторов [ править ]

На рисунке слева показано, как архитектура большой системы Берроуза была в основном аппаратной архитектурой для объектно-ориентированного программирования , чего до сих пор не существует в традиционных архитектурах.

Наборы инструкций [ править ]

Для больших систем Берроуза существует три различных набора инструкций. Все три основаны на коротких слогах, которые равномерно укладываются в слова.

B5000, B5500 и B5700 [ править ]

Программы на B5000, B5500 и B5700 состоят из 12-битных слогов , по четыре в слово. В архитектуре есть два режима, режим слов и режим символов, и каждый имеет отдельный набор слогов. Процессор может находиться либо в контрольном, либо в нормальном состоянии, а определенные слоги допустимы только в контрольном состоянии. Архитектура не предусматривает прямой адресации регистров или хранилища; все ссылки осуществляются через справочную таблицу программы из 1024 слов, текущий сегмент кода, отмеченные места в стеке или регистры A и B, содержащие два верхних места в стеке. Берроуз нумерует биты в слоге от 0 (старший бит) до 11 (младший бит)

B6500, B7500 и последующие [ править ]

Программы состоят из 8-битных слогов , которые могут быть именными, значимыми или операторами, длина которых может составлять от одного до двенадцати слогов. Есть менее 200 операторов , каждый из которых укладывается в 8-битные слоги. Многие из этих операторов являются полиморфными в зависимости от типа данных, с которыми работают, как указано в теге. Если игнорировать мощные операторы сканирования, передачи и редактирования строк, базовый набор составляет всего около 120 операторов. Если мы удалим операторы, зарезервированные для операционной системы, такие как MVST и HALT, набор операторов, обычно используемых программами пользовательского уровня, будет меньше 100. Слоги Name Call и Value Call содержат пары адресов.; слоги оператора либо не используют адреса, либо используют управляющие слова и дескрипторы в стеке.

Несколько процессоров [ править ]

Линия B5000 также была пионером в соединении нескольких процессоров на высокоскоростной шине. Линия B7000 могла иметь до восьми процессоров, если хотя бы один был модулем ввода-вывода. RDLK - это очень низкоуровневый способ синхронизации между процессорами. Высокий уровень, используемый пользовательскими программами, - это тип данных EVENT. Тип данных EVENT имел некоторые системные издержки. Чтобы избежать этих накладных расходов, можно использовать специальный метод блокировки, называемый замками Дама (названный в честь гуру программного обеспечения Берроуза Дэйва Дама).

Известные операторы:

HEYU - отправить прерывание другому процессору.
RDLK - Оператор семафора низкого уровня: загрузить в регистр A ячейку памяти, заданную регистром A, и поместить значение в регистр B в этой ячейке памяти за один непрерывный цикл. Компилятор Algol создал код для вызова этого оператора через специальную функцию, которая позволяет выполнять операцию «подкачки» для однословных данных без явного временного значения. x:=RDLK(x,y);
WHOI - Идентификация процессора
IDLE - Ожидание до получения прерывания

Два процессора нечасто могли одновременно отправлять друг другу команду «HEYU», что приводило к блокировке, известной как « смертельные объятия ».

Влияние B5000 [ править ]

Прямое влияние B5000 можно увидеть в текущей линейке мэйнфреймов Unisys ClearPath, которые являются прямыми потомками B5000 и все еще имеют операционную систему MCP после 40 лет последовательной разработки. Эта архитектура теперь называется emode (для режима эмуляции), поскольку архитектура B5000 была реализована на машинах, построенных на процессорах Intel Xeon , использующих набор инструкций x86 в качестве собственного набора инструкций, при этом код, выполняемый на этих процессорах, эмулирует набор инструкций B5000. В этих машинах также должен был быть nmode ( собственный режим ), но от него отказались ^{[ необходима цитата ]} , поэтому вы часто можете слышать, как машины-преемники B5000 называются «машинами эмоций».

Машины B5000 были запрограммированы исключительно на языках высокого уровня; нет ассемблера.

Архитектура стека B5000 вдохновила Чака Мура , разработчика языка программирования Forth , который столкнулся с B5500 во время работы в Массачусетском технологическом институте. В книге Forth - The Early Years Мур описал влияние, отметив, что DUP, DROP и SWAP Форта исходили из соответствующих инструкций B5500 (DUPL, DLET, EXCH).

Машины B5000 с их архитектурой на основе стека и маркированной памятью также сильно повлияли на советскую серию мэйнфреймов и суперкомпьютеров Эльбрус . В первых двух поколениях этой серии использовались процессоры на базе тегов памяти и стека, которые были запрограммированы только на языках высокого уровня. Для них существовал своего рода ассемблер , называвшийся Эль-76, но он был более или менее модификацией АЛГОЛА 68 и поддерживал структурное программирование и первоклассные процедуры. Последующие поколения этой серии, хотя, перешли от этой архитектуры к EPIC -like VLIW процессоров .

В Hewlett-Packard Конструкторы HP 3000 бизнес - системы использовала B5500 и были очень впечатлены его аппаратного и программного обеспечения; они стремились создать 16-битный миникомпьютер с аналогичным программным обеспечением. Несколько других подразделений HP создали аналогичные мини-компьютеры или микропроцессорные стековые машины. Работа Боба Бартона над обратной польской нотацией (RPN) также нашла свое отражение в калькуляторах HP, начиная с модели 9100A, особенно в калькуляторах HP-35 и последующих.

Системы NonStop, разработанные Tandem Computers в конце 1970-х и начале 1980-х годов, также были 16-разрядными стековыми машинами, на которые B5000 оказал косвенное влияние через соединение HP 3000, поскольку некоторые из первых инженеров Tandem ранее работали в HP. Примерно в 1990 году эти системы перешли на архитектуру MIPS RISC, но продолжали поддерживать выполнение двоичных файлов стековых машин путем преобразования объектного кода или прямой эмуляции. Где-то после 2000 года эти системы перешли на архитектуру Itanium и продолжали использовать устаревшие двоичные файлы стековых машин.

Боб Бартон также оказал большое влияние на Алана Кея . Кей также был впечатлен архитектурой B5000 с тегами, управляемой данными, и это повлияло на его мышление при разработке объектно-ориентированного программирования и Smalltalk . ^{[ необходима цитата ]}

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

Ценность привязки аппаратной архитектуры к архитектуре, существовавшей до emode, будет в значительной степени сохранена на машинах на базе x86 в той степени, в которой MCP была единственной управляющей программой, но поддержка, предоставляемая этими машинами, все еще уступает той, которая предоставлялась на машины, где набор инструкций B5000 является родным набором инструкций. Малоизвестный архитектуры процессора Intel , который фактически предшествует 32-битных реализаций набора инструкций x86, то Intel iAPX 432 , было бы обеспечили эквивалентную физическую основу, так как он тоже был по существу объектно-ориентированной архитектурой.

См. Также [ править ]

• Средние системы Берроуза
• Малые системы Берроуза
• КАНДА
• Язык определения сети (NDL)
• Язык рабочего процесса (WFL)
• Восьмеричная плавающая точка

Примечания [ править ]

Ссылки [ править ]

• Расширенный учебник по Алголу (три тома), Дональд Дж. Грегори.
• Компьютерная архитектура: структурированный подход, Р. Доран, Academic Press (1979).
• Stack Computers: The New Wave, Philip J. Koopman, доступно по адресу: [1]
• Руководства по B5500, B6500, B6700, B6800, B6900, B7700 доступны по адресу: bitsavers.org

Дальнейшее чтение [ править ]

• Бартон, Роберт С. «Новый подход к функциональному дизайну цифрового компьютера» Труды Западной совместной компьютерной конференции. ACM (1961).
• Берроуз B 5000 Устная история , Институт Чарльза Бэббиджа , Университет Миннесоты. Компьютерная серия Burroughs 5000 обсуждается лицами, ответственными за ее разработку и маркетинг с 1957 по 1960-е годы на конференции 1985 года, спонсируемой AFIPS и Burroughs Corporation .
• Грей, Джордж (март 1999). "Некоторые транзисторные компьютеры Берроуза" . Информационный бюллетень Unisys History . 3 (1). Архивировано из оригинала на 1 октября 2016 года.
• Грей, Джордж (октябрь 1999 г.). «Компьютеры Берроуза третьего поколения» . Информационный бюллетень Unisys History . 3 (5). Архивировано из оригинального 26 сентября 2017 года.
• Хаук, Э.А., Дент, Бен А. "Механизм штабелирования Burroughs B6500 / B7500", SJCC (1968), стр. 245–251.
• МакКиман, Уильям М. «Компьютерный дизайн, управляемый языком», Fall Joint Computer Conference, (1967), стр. 413–417.
• Органик, Эллиот И. "Организация компьютерных систем серии B5700 / B6700" , Academic Press (1973).
• Уэйчофф, Ричард, «Истории о B5000 и людях, которые там были» , 27 сентября 1979 г. [2]
• Аллвейс, Джек. «Burroughs B5900 и E-Mode A bridge to 21st Century Computing» , редакция 2010 г.
• Мартин, Ян. «« Слишком далеко впереди своего времени »: Великобритания, Берроуз и банковское дело в реальном времени в 1960-х» , Ежегодное собрание Общества истории технологий, 20 сентября - 3 октября 2010 г., Такома, США.

Внешние ссылки [ править ]

• Страница Яна Джойнера Берроуза
• Burroughs B5900 и E-Mode: мост к вычислениям 21 века - Джек Олвейс
• (Интернет-архив :) Ральф Климек на B7800 в университете Монаша
• "Ранние машины Берроуза" , Компьютерный музей Университета Вирджинии .
• "Организация компьютерных систем" , Серия монографий ACM.
• Указатель руководств B8500
• B5500 Emulation Project Проект по созданию функционального эмулятора для компьютерной системы Burroughs B5500.
• "Берроуз B6500 фильм и стенограмма"