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

Группа компаний Burroughs Large Systems создала семейство больших 48-битных мэйнфреймов , использующих стековых машинных наборы команд с плотным набором слогов . Первой машиной в семействе была B5000 в 1961 году, которая была оптимизирована для очень хорошей компиляции программ ALGOL 60 с использованием однопроходных компиляторов. B5000 превратился в B5500 (диск, а не барабан) и B5700 (до четырех систем, работающих в кластере). Последующие крупные модификации включают линейку B6500/B6700 и ее преемников, а также отдельную линейку B8500.

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

Предыстория

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

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

B5000, B5500 и B5700

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

Особенности

• Аппаратное обеспечение было разработано с учетом требований к программному обеспечению.
• Аппаратное обеспечение, предназначенное исключительно для поддержки языков программирования высокого уровня.
• Упрощенный набор инструкций
• Нет языка ассемблера или ассемблера; все системное программное обеспечение написано на расширенной версии АЛГОЛА 60 под названием ESPOL . Однако в ESPOL были утверждения для каждого слога архитектуры.
• Частично управляемый данными тегов и дескрипторов дизайн на основе
• Мало регистров, доступных программисту
• Стековая машина , в которой все операции используют стек, а не явные операнды. К настоящему времени этот подход вышел из моды.
• Все прерывания и вызовы процедур используют стек.
• Поддержка других языков, таких как COBOL.
• Мощные манипуляции со строками
• Весь код автоматически реентерабельен : программистам не нужно ничего делать, чтобы код на любом языке распределялся по процессорам, кроме как использовать только два показанных простых примитива.
• Поддержка операционной системы (MCP, Master Control Program )
• Поддержка асимметричной (главный/подчиненный). многопроцессорной обработки
• Попытка создать безопасную архитектуру, запрещающую несанкционированный доступ к данным или сбои в работе.
• Раннее обнаружение ошибок, поддержка разработки и тестирования программного обеспечения
• Коммерческая реализация виртуальной памяти, которой предшествовал только Ferranti Atlas .
• Первая модель сегментированной памяти

Проектирование системы

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

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

B5x00 Относительная адресация

МАЗЬ	Т0 А38	Т1 А39	Т2 А40	МСФФ	База	Содержание	Индексный знак	Индекс Биты	Макс Индекс
ВЫКЛЮЧЕННЫЙ	-	-	-	-	р	Адрес ПРТ	+	Т 0-9 А 38-47	1023
НА	ВЫКЛЮЧЕННЫЙ	-	-	-	р	Адрес ПРТ	+	Т 1-9 А 39-47	511
НА	НА	ВЫКЛЮЧЕННЫЙ	-	ВЫКЛЮЧЕННЫЙ	Ф	Адрес последнего RCW или МСКВ в стопке	+	Т 2-9 40-47	255
НА	НА	ВЫКЛЮЧЕННЫЙ	-	НА	(Р+7)	F зарегистрироваться из MSCW на PRT+7	+	Т 2-9 40-47	255
НА	НА	НА	ВЫКЛЮЧЕННЫЙ	-	С	Адрес текущего командного слова	+	Т 3-9 А 41-47	127
НА	НА	НА	НА	ВЫКЛЮЧЕННЫЙ	Ф	Адрес последнего RCW или МСКВ в стопке	-	Т 3-9 А 41-47	127
НА	НА	НА	НА	НА	(Р+7)	F зарегистрироваться из MSCW на PRT+7	-	Т 3-9 А 41-47	127
Примечания:

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

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

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

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

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

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

B6700/B7700 и

См. Также: Набор инструкций Берроуза B6x00-7x00.

В6500 (поставка 1969 г. ) и B7500 были первыми компьютерами из единственной линейки систем Берроуза, сохранившимися до наших дней. Хотя они были вдохновлены B5000, у них была совершенно новая архитектура. Среди наиболее важных отличий были

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

Среди других заказчиков B6700 и B7700 были все пять университетов Новой Зеландии в 1971 году.

Б8500

В8500 линия происходит от D825, военный компьютер, вдохновленный B5000.

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

История

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

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

Берроуз (1961–1986)
Б5000	1961	начальная система, компьютер 2-го поколения (транзисторный)
Б5500	1964	Увеличение скорости в 3 раза
Б6500	1969	Компьютер 3-го поколения (интегральные схемы), до 4 процессоров
Б5700	1971	новое имя для B5500
Б6700	1971	новое имя/исправление ошибки для B6500
Б7700	1972	более быстрый процессор, кэш для стека, до 8 запросчиков (процессоры ввода-вывода или центральные процессоры) в одном или двух разделах.
Б6800	1977?	полупроводниковая память, NUMA архитектура
Б7800	1977?	полупроводниковая память, более быстрая, до 8 запросчиков (процессоры ввода-вывода или центральные процессоры) в одном или двух разделах.
Б6900	1979?	полупроводниковая память, архитектура NUMA . Максимум 4 процессора B6900, привязанных к локальной памяти и общей глобальной памяти(tm).
Б5900	1981	полупроводниковая память, архитектура NUMA . Максимум 4 процессора B5900, привязанных к локальной памяти и общей глобальной памяти II (tm)
Б7900	1982?	полупроводниковая память, более быстрая, кэши кода и данных, NUMA архитектура , 1-2 HDU (ввод-вывод), 1-2 точки доступа, 1-4 процессора. Мягкая реализация памяти NUMA позволяла процессорам перемещаться из одного пространства памяти в другое.
А9/А10	1984	Класс B6000, первый конвейерный процессор среднего класса, один ЦП (два на A10), первый, поддерживающий eMode Beta (расширенная адресация памяти)
А12/А15	1985	Класс B7000, повторно реализован в специально разработанных Motorola ECL MCA1, затем вентильных матрицах MCA2 , один ЦП, один HDU (A12) 1–4 ЦП, 1–2 HDU (A15)
Unisys (1986 – настоящее время)
Микро А	1989	настольный «мэйнфрейм» с однокристальным SCAMP процессор.
Clearpath HMP NX 4000	1996?	?
Clearpath HMP NX 5000	1996?	?
Clearpath HMP LX 5000	1998	Реализует большие системы Burroughs только в режиме эмуляции ( Xeon ). процессоры
Весы 100	2002?	??
Весы 200	200?	??
Весы 300	200?	??
Весы 400	200?	??
Весы 500	2005?	например Весы 595
Весы 600	2006?	??
Весы 700	2010	например, 750 фунтов стерлингов

Основные направления аппаратного обеспечения

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

ALGOL

Основная статья: АЛГОЛ

Берроуз Алгол

Парадигмы	Мультипарадигмальность : процедурная , императивная , структурированная.
Семья	АЛГОЛ
Разработано	Джон МакКлинток и другие
Разработчик	Корпорация Берроуза
Впервые появился	1962 год ( 1962 )
Платформа	Большие системы Берроуза
ТЫ	Берроуз MCP
Под влиянием
АЛГОЛ 60
Под влиянием
ESPOL , MCP , НЬЮП

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

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

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

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

ESPOL и NEWP

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

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

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

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

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

Начиная с начала 1980-х годов, технология DCP была заменена ICP (интегрированным коммуникационным процессором), который обеспечивал подключение по локальной сети для мэйнфреймов. Удаленные устройства и удаленные серверы/мэйнфреймы подключались к сети через автономные устройства под названием CP2000. CP2000 были разработаны для обеспечения поддержки сетевых узлов в распределенной сети, в которой узлы были соединены с использованием сетевой технологии BNAV2 (Burroughs Network Architecture Version 2). BNAV2 был функциональным эквивалентом продукта IBM SNA компании Burroughs и поддерживал взаимодействие со средами IBM как в транспортных режимах PUT2, так и в PUT5. Изменение внешнего оборудования для передачи данных не потребовало каких-либо изменений в существующем программном обеспечении MCS (система управления сообщениями (обсуждается ниже)).

При вводе сообщения передавались из DCP по внутренней шине в соответствующий стек процессов DCP MCP Datacom Control (DCC). Для каждого DCP, настроенного в системе, был инициирован один процесс DCC. Затем стек процессов DCP гарантирует, что входящее сообщение будет поставлено в очередь для доставки в MCS, идентифицированный для обработки трафика от конкретного исходного устройства, и вернет любой ответ DCP для доставки на устройство назначения. С точки зрения обработки не требовалось никаких изменений в программном обеспечении MCS для работы с различными типами шлюзового оборудования, будь то любой из 5 стилей DCP или комбинации ICP или ICP/CP2000.

Помимо службы доставки сообщений, MCS представляет собой промежуточный уровень безопасности между кодом операционной системы (в NEWP) и пользовательскими программами (в ALGOL или других прикладных языках, включая COBOL, FORTRAN и, в более поздние времена, JAVA). MCS можно рассматривать как промежуточное программное обеспечение, написанное на DCALGOL (ALGOL для передачи данных). Как указано выше, MCS получал сообщения из очередей, поддерживаемых стеком управления Datacom (DCC), и пересылал эти сообщения соответствующему приложению/функции для обработки. Одной из первых MCS была CANDE (Command AND Edit), которая была разработана как онлайн-среда разработки программ. Университет Отаго в Новой Зеландии разработал упрощенную среду разработки программ, эквивалентную CANDE, которую они назвали SCREAM/6700, в то же время, когда IBM предлагала удаленную службу разделения времени и разработки программ, известную как CALL/360, которая работала на IBM 360 series. системы. Другая MCS, названная COMS, была представлена ​​примерно в 1984 году и разработана как высокопроизводительная система управления обработкой транзакций. Существовали предшествующие среды обработки транзакций, которые включали GEMCOS (GENeralized Message Control System), а австралийская дочерняя компания Burroughs разработала MCS под названием TPMCS (MCS для обработки транзакций). Обработка транзакций MCS поддерживала доставку данных приложений в производственные онлайн-среды и возврат ответов удаленным пользователям/устройствам/системам.

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

Примерно в 1988 году реализация TCP/IP была разработана главным образом для заказчика из правительства США, использующего процессор распределенных коммуникаций CP2000 в качестве хоста протокола. Два-три года спустя реализация TCP/IP была переписана на основе хоста/сервера со значительными улучшениями производительности и функциональности. В те же общие сроки была реализована реализация стеков протоколов OSI, в основном на CP2000, но в основной системе была реализована большая вспомогательная инфраструктура. Были реализованы все приложения, определенные стандартом OSI, включая почтовый хостинг X.400 и службы каталогов X.500.

DMALGOL и базы данных

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

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

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

Версия ALGOL для приложений, поддерживающая доступ к базам данных из прикладных программ, называется BDMSALGOL и включает такие команды, как «FIND», «LOCK», «STORE», «GET» и «PUT» для доступа к базе данных и манипулирования записями. Кроме того, глаголы «BEGINTRANSACTION» и «ENDTRANSACTION» также были реализованы для решения ситуации взаимоблокировки, когда несколько процессов обращались к одним и тем же структурам и обновляли их.

Рой Гак из Burroughs был одним из главных разработчиков DMSII .

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

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

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

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

Б5000, Б5500, Б5700

Инициировать P1 (IP1) и Инициировать P2 (IP2)

B6500, B7500 и последующие модели

MVST (перемещение стека).

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

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

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

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

Таким образом, разработчики нынешних преемников систем B5000 могут оптимизировать любую новейшую технику, а программистам не нужно корректировать свой код, чтобы он работал быстрее – им даже не нужно перекомпилировать, что защищает инвестиции в программное обеспечение. Известно, что некоторые программы работают годами при многих обновлениях процессора. Такое ускорение ограничено на машинах с регистрами.

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

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

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

Вот пример того, как программы сопоставляются со структурой стека.

начинать 
     — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
     — Это лексический уровень 2 (нулевой уровень зарезервирован для операционной системы, а уровень 1 — для сегментов кода). 
     — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
   
     — На уровне 2 мы размещаем глобальные переменные для нашей программы. 
   
     целое число   я  ,  j  ,  k  ; 
     реальный   ж  ,  г  ; 
     массив   а  [0:9]; 
   
     процедура   p  (  действительная   p1  ,  p2  ); 
        значение   p1  ;   — p1 передается по значению, p2 неявно передается по ссылке. 
        начинать 
           — — — — — — — — — — — — — — — — — — — 
           — Этот блок находится на лексическом уровне 3. 
           — — — — — — — — — — — — — — — — — — — 
           действительный   r1  ,  r2  ; 

         г2  :=  р1  *  5  ; 
           р2  :=  г2  ;   — Это устанавливает  g  в значение  r2 
          p1  :=  r2  ;   — Это устанавливает  p1  в  r2  , но не  в f 
           — Поскольку это перезаписывает исходное значение  f  в  p1  , это  может  быть 
           — ошибка кодирования.   Поэтому некоторые из преемников Алгола настаивают на том, что 
           — параметры-значения доступны только для чтения, но большинство из них этого не делают. 
         
           если   r2  >  10   , то 
             начнем 
                 — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
                 — Объявленная здесь переменная делает этот лексический уровень 4 
                 — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
                 целое число   n  ; 
— Объявление переменной делает это блоком, который будет вызывать некоторые 
                 — код сборки стека.   Обычно вы не объявляете здесь переменные, в которых 
                 — в этом случае это будет составной оператор, а не блок. 
               
                 ... <== где-то здесь выполняется образец стека. 
              конец  ; 
        конец  ; 
      
     ..... 
   
     п  (  ж  ,  г  ); 
  конец  . 
 

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

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

Процедуры

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

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

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

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

Тип вызова

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

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

Встроенные процедуры

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

Асинхронные вызовы

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

Регистры отображения

Аппаратная оптимизация стека — это предоставление регистров D (или «дисплея»). Это регистры, которые указывают на начало каждого вызываемого кадра стека. Эти регистры обновляются автоматически при входе и выходе из процедур и недоступны никакому программному обеспечению, кроме MCP. Имеется 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  (объявляется при входе в блок, а не в процедуру) 
  |-----------------------| 
  |   Д[4]==>3 |   МСКВ  |   (4, 0) Управляющее слово стека меток, содержащее ссылку на D[3]. 
  |======================| 
  |   0 |   р2  |   (3, 5) Реальный  r2 
  |-----------------------| 
  |   0 |   р1  |   (3, 4) Действительный  r1 
  |-----------------------| 
  |   1 |   р2  |   (3, 3) Ссылка SIRW на  g  в (2,6) 
  |-----------------------| 
  |   0 |   р1  |   (3, 2) Параметр  p1  из значения  f  
  |-----------------------| 
  |   3 |   РКВ  |   (3, 1) Возвращаемое управляющее слово 
  |-----------------------| 
  |   Д[3]==>3 |   МСКВ  |   (3, 0) Управляющее слово стека меток, содержащее ссылку на D[2]. 
  |======================| 
  |   1 |   а  |   (2, 7) Массив  a  ======>[блок памяти из десяти слов] 
  |-----------------------| 
  |   0 |   г  |   (2, 6) Действительное  g  
  |-----------------------| 
  |   0 |   ж  |   (2, 5) Реальное  f  
  |-----------------------| 
  |   0 | к  |   (2, 4) Целое число  k  
  |-----------------------| 
  |   0 |   й  |   (2, 3) Целое число  j  
  |-----------------------| 
  |   0 |   я  |   (2, 2) Целое число  i 
  |-----------------------| 
  |   3 |   РКВ  |   (2, 1) Возвращаемое управляющее слово 
  |-----------------------| 
  |   Д[2]==>3 |   МСКВ  |   (2, 0) Управляющее слово стека пометок, содержащее ссылку на предыдущий кадр стека. 
  |======================|   — Нижняя часть стека 
 

Если бы мы вызвали процедуру 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] во время операций ввода-вывода. В начале девяностых эта возможность была реализована как языковая функция в виде СТРУКТУРНЫХ БЛОКОВ и – в сочетании с библиотечной технологией – как СОЕДИНИТЕЛЬНЫЕ БЛОКИ. Возможность связать структуру данных с областью адреса регистра отображения реализовала объектную ориентацию. Таким образом, в B6500 фактически использовалась форма объектной ориентации задолго до того, как этот термин стал использоваться.

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

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

Хранилище массива

Массивы не хранились в памяти рядом с другими переменными, каждому из них было предоставлено собственное адресное пространство, которое располагалось через дескриптор. Механизм доступа заключался в том, чтобы вычислить в стеке индексную переменную (которая, следовательно, имела потенциал полного целочисленного диапазона, а не только четырнадцать бит) и использовать ее в качестве смещения в адресном пространстве массива с проверкой привязки, обеспечиваемой аппаратным обеспечением. По умолчанию, если длина массива превышает 1024 слова, массив будет сегментирован, а индекс преобразуется в индекс сегмента, а смещение — в индексированный сегмент. Однако существовала возможность предотвратить сегментацию, указав в объявлении массив как LONG. В случае АЛГОЛА многомерный массив будет использовать несколько уровней такой адресации. Для ссылки на A[i,j] первый индекс будет относиться к массиву дескрипторов, по одному дескриптору для каждой строки A, какая строка затем будет индексироваться с помощью j, как для одномерного массива, и так для более высоких измерений. Аппаратная проверка известных границ всех индексов массива предотвратит ошибочную индексацию.

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

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

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

Также поддерживается эквивалентность массивов. Объявление ARRAY требовало выделения 48-битных слов данных, которые можно было использовать для хранения любого битового шаблона, но общая практика заключалась в том, что каждое выделенное слово считалось НАСТОЯЩИМ операндом. Декларация:

 МАССИВ А [0:99]
 

запросил выделение 100 слов типа REAL в пространстве данных в памяти. Программист также может указать, что память может называться символьно-ориентированными данными, с помощью следующего объявления эквивалентности:

 EBCDIC МАССИВ EA [0] = A [*];
 

или в виде шестнадцатеричных данных через декларацию эквивалентности:

 ШЕСТИНСТВЕННЫЙ МАССИВ HA [0] = A [*];
 

или как данные ASCII через декларацию эквивалентности:

 ASCII МАССИВ AA [0] = A[*];
 

Также поддерживается возможность запрашивать массивы конкретных типов данных без эквивалентности, например

 EBCDIC МАССИВ MY_EA [0:99]
 

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

Дескриптор данных, созданный во время компиляции, указывает использование типа данных, для которого предназначен массив. Если было сделано объявление эквивалентности массива, был создан дескриптор копии, указывающий, что конкретный тип использования был сгенерирован, но указывал обратно на исходный дескриптор (MOM). Таким образом, всегда гарантировалась индексация правильного места в памяти.

Также поддерживаются BOOLEAN-массивы, которые можно использовать как битовые вектора. Также могут быть запрошены массивы INTEGER.

Непосредственно предшествующее обсуждение использует реализацию синтаксиса ALGOL для описания объявлений ARRAY, но та же функциональность поддерживается в COBOL и FORTRAN.

структуры

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

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

Таким образом, FORTRAN Берроуза имел лучшую проверку ошибок, чем другие современные реализации FORTRAN. Например, для подпрограмм и функций проверялось, что они были вызваны с правильным количеством параметров, как это обычно бывает для компиляторов в стиле ALGOL. На других компьютерах такие несоответствия были распространенной причиной сбоев. Аналогично и с проверкой привязки к массиву: программы, которые годами использовались в других системах, до неловкости часто терпели неудачу при запуске в системе Burroughs. Фактически, Берроуз стал известен своими превосходными компиляторами и реализацией языков, включая объектно-ориентированное моделирование (расширение АЛГОЛА), а Айверсон , разработчик APL , заявил, что реализация APL Берроуза была лучшей, которую он видел. Джон Маккарти , разработчик языка LISP , не согласился с этим, поскольку LISP был основан на модифицируемом коде. , ему не понравился немодифицируемый код В5000 , но большинство реализаций LISP в любом случае будут работать в интерпретирующей среде.

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

Tagged архитектура

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

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

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

Ярлык	Слово вид	Описание
0	Данные	Все виды пользовательских и системных данных (текстовые данные и числа одинарной точности)
2	Двойной	Данные двойной точности
4	СИВ	Индексное слово шага (используется в циклах)
6		Неинициализированные данные
	SCW	Программное управляющее слово (используется для сокращения стека)
1	ИРВ	Косвенное справочное слово
	СИРВ	Фаршированное косвенное справочное слово
3	Код	Кодовое слово программы
	МСКВ	Отметить управляющее слово стека
	РКВ	Возврат управляющего слова
	ТОСКВ	Управляющее слово вершины стека
	СД	Дескриптор сегмента
5	Дескриптор	Дескрипторы блоков данных
7	ПКВ	Слово управления программой

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

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

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

Слова тега 1 представляют адреса данных в стеке. Обычный IRW просто сохраняет пару адресов с данными в текущем стеке. SIRW ссылается на данные в любом стеке, включая номер стека в адрес. Помимо прочего, SIRW используются для обеспечения адресации между дискретными стеками процессов, например, сгенерированными в ответ на операторы CALL и PROCESS .

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

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

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

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

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

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

Основная статья: Дескрипторы больших систем Берроуза

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

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

B5000, B5500 и B5700

Основная статья: Набор инструкций B5000

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

B6500 и его преемники

Основная статья: Набор инструкций Берроуза B6x00-7x00

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

Несколько процессоров

Линия B5000 также была пионером в использовании двух процессоров, соединенных вместе по высокоскоростной шине в качестве ведущего и ведомого. В линейках B6000, B7000 и B8000 процессоры были симметричными. Линия B7000 могла иметь до восьми процессоров, при условии, что хотя бы один из них был модулем ввода-вывода. RDLK (ReaD с LocK) — это очень низкоуровневый способ синхронизации между процессорами. РДЛК работает в одном цикле. Механизм более высокого уровня, обычно используемый пользовательскими программами, — это тип данных EVENT . Тип данных EVENT действительно имел некоторые системные издержки. Чтобы избежать этих накладных расходов, можно использовать специальную технику блокировки, называемую замками Дама (названной в честь гуру программного обеспечения Burroughs, Дэйва Дама). Замки Дама использовали оператор языка READLOCK ALGOL, который генерировал оператор RDLK на уровне кода.

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

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

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

Влияние B5000

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

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

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

Машины B5000 с их стековой архитектурой и тегированной памятью также сильно повлияли на советскую «Эльбрус» серию мэйнфреймов и суперкомпьютеров . Первые два поколения этой серии имели тегированную память и процессоры на основе стека, которые программировались только на языках высокого уровня. Для них существовал своего рода ассемблер под названием Эль-76, но он был более или менее модификацией АЛГОЛА 68 и поддерживал структурное программирование и первоклассные процедуры. Однако более поздние поколения серии перешли от этой архитектуры к EPIC -подобным процессорам 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 была единственной управляющей программой, но поддержка, предоставляемая этими машинами, по-прежнему уступала той, которая предоставлялась на машинах с процессором x86. машины, где набор инструкций B6500 является собственным набором команд. Малоизвестная архитектура процессора Intel, которая фактически предшествовала 32-битным реализациям набора команд x86, Intel iAPX 432 , могла бы обеспечить эквивалентную физическую основу, поскольку она тоже была по существу объектно-ориентированной архитектурой.

См. также

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

Ссылки

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

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

• Бартон, Роберт С. (1961). «Новый подход к функциональному проектированию цифрового компьютера». Материалы Западной объединенной компьютерной конференции . АКМ. дои : 10.1145/1460690.1460736 .
• Уэйчофф, Ричард; Тернер, Ллойд; Розин, Роберт Ф.; Пирсон, Ральф В.; Олифинт, Дж. Кларк; Маккензи, Ф. Брэд; Макдональд, Рэй В.; Макдональд, Дункан Н.; Лонерган, Уильям Д.; Кройдер, Норман Л.; Кинг, Пол Д.; Хутман, Джозеф Т.; Хаук, Эрвин А.; Хейл, Джон Э.; Галлер, Бернард А.; Форд, Джеймс; Эпперт, Рэй Р.; Дент, Бенджамин А.; Дам, Дэвид М.; Крич, Бобби А.; Коллинз, Джордж А.; Берс, Анри; Бартон, Роберт С. (6 сентября 1985 г.). «Конференция Берроуза B 5000» . Институт Чарльза Бэббиджа , Университет Миннесоты . Серия компьютеров Burroughs 5000 обсуждается лицами, ответственными за ее разработку и маркетинг с 1957 по 1960-е годы, на конференции 1985 года, спонсируемой AFIPS и Burroughs Corporation .
• Грей, Джордж (март 1999 г.). «Некоторые транзисторные компьютеры Берроуза» . Информационный бюллетень об истории Unisys . 3 (1). Архивировано из оригинала 1 октября 2016 года.
• Gray, George (October 1999). "Burroughs Third-Generation Computers". Unisys History Newsletter. 3 (5). Archived from the original on September 26, 2017.
• Hauck, E.A.; Dent, Ben A. (1968). Burroughs B6500/B7500 Stack Mechanism. Spring Joint Computer Conference. pp. 245–251. doi:10.1145/1468075.1468111.
• McKeeman, William M. (1967). Language Directed Computer Design. Fall Joint Computer Conference. pp. 413–417. doi:10.1145/1465611.1465665.
• Organick, Elliot I. (1973). Computer System Organization The B5700/B6700 series (PDF). Academic Press.
• Waychoff, Richard (September 27, 1979). "Stories of the B5000 and People Who Were There" (PDF). Archived from the original (PDF) on March 4, 2016. [2]
• Allweiss, Jack. "The Burroughs B5900 and E-Mode A bridge to 21st Century Computing Revised 2018".
• 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.

External links

• 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", University of Virginia'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"