Burroughs Large Systems Group выпустила семейство больших 48-битных мэйнфреймов, использующих наборы команд стековой машины с плотными слогами . [NB 1] Первой машиной в семействе была B5000 в 1961 году, которая была оптимизирована для компиляции программ ALGOL 60 чрезвычайно хорошо, используя однопроходные компиляторы. B5000 эволюционировала в B5500 (диск, а не барабан) и B5700 (до четырех систем, работающих как кластер). Последующие крупные модернизации включают линейку B6500/B6700 и ее преемников, а также отдельную линейку B8500.
В 1970-х годах корпорация Burroughs была разделена на три подразделения с очень разными архитектурами линеек продуктов для высокопроизводительных, среднепроизводительных и начального уровня бизнес-компьютерных систем. Линейка продуктов каждого подразделения выросла из разных концепций оптимизации набора инструкций компьютера для определенных языков программирования. «Большие системы Burroughs» относились ко всем этим линейкам продуктов для больших систем вместе, в отличие от оптимизированных для COBOL средних систем (B2000, B3000 и B4000) или малых систем с гибкой архитектурой (B1000).
Основанная в 1880-х годах, Burroughs была старейшей непрерывно работающей компанией в области вычислительной техники ( Elliott Brothers была основана до Burroughs, но не производила вычислительные устройства в 19 веке). К концу 1950-х годов ее вычислительное оборудование все еще ограничивалось электромеханическими счетными машинами, такими как Sensimatic . Ей нечем было конкурировать со своими традиционными конкурентами IBM и NCR , которые начали производить более крупные компьютеры, или с недавно основанной Univac . В 1956 году они приобрели ElectroData Corporation и переименовали ее конструкцию в B205.
Первая машина собственной разработки Burroughs, B5000, была разработана в 1961 году, и Burroughs стремилась решить проблему своего позднего выхода на рынок с помощью стратегии совершенно иного дизайна, основанного на самых передовых идеях вычислений, доступных в то время. Хотя архитектура B5000 мертва, она вдохновила B6500 (и последующие B6700 и B7700). Компьютеры, использующие эту архитектуру, [ требуется ссылка ] все еще производились как серверы Unisys ClearPath Libra, которые работают на усовершенствованной, но совместимой версии операционной системы MCP , впервые представленной с B6700. Третья и самая большая линейка, B8500, [1] [2] не имела коммерческого успеха. В дополнение к фирменной конструкции процессора CMOS , Unisys также использует процессоры Intel Xeon и запускает операционные системы MCP , Microsoft Windows и Linux на своих серверах Libra; использование специальных чипов постепенно устранялось, и к 2018 году серверы Libra были строго товарными Intel в течение нескольких лет.
Первый представитель первой серии, B5000, [3] был разработан в 1961 году командой под руководством Роберта (Боба) Бартона . Он имел необычную архитектуру. Он был перечислен ученым-компьютерщиком Джоном Маши как одна из архитектур, которой он восхищается больше всего. «Я всегда думал, что это один из самых инновационных примеров комбинированного дизайна оборудования и программного обеспечения, который я видел, и который намного опередил свое время». [4] За B5000 последовал B5500, [5] который использовал диски вместо барабанного хранилища, и B5700, который позволял объединять несколько ЦП вокруг общего диска. Хотя у B5700 не было преемника, линейка B5000 сильно повлияла на дизайн B6500, и Burroughs перенес Master Control Program ( MCP ) на эту машину.
B5000 был необычен в то время, поскольку архитектура и набор инструкций были разработаны с учетом потребностей программного обеспечения. Это было большим отходом от проектирования компьютерных систем того времени, когда процессор и его набор инструкций проектировались, а затем передавались программистам.
B5000, B5500 и B5700 в режиме Word имеют два различных режима адресации в зависимости от того, выполняет ли он основную программу (SALF выключен) или подпрограмму (SALF включен). Для основной программы поле T слога вызова операнда или вызова дескриптора относительно таблицы ссылок на программы (PRT). Для подпрограмм тип адресации зависит от старших трех бит T и триггера стека метки (MSFF), как показано в B5x00 Relative Addressing.
B5000 был разработан исключительно для поддержки языков высокого уровня. Это было в то время, когда такие языки только начинали приобретать известность с появлением FORTRAN, а затем COBOL . Некоторые считали FORTRAN и COBOL более слабыми языками, когда дело касалось современных методов программирования, поэтому был принят более новый, в основном неиспытанный язык ALGOL-60 . Диалектом ALGOL, выбранным для B5000, был Elliott ALGOL , впервые разработанный и реализованный CAR Hoare на Elliott 503. Это было практическое расширение ALGOL с инструкциями ввода-вывода (которые ALGOL игнорировал) и мощными инструкциями по обработке строк. Знаменитая лекция Хоара на премии Тьюринга была посвящена этой теме.
Таким образом, B5000 был основан на очень мощном языке. Дональд Кнут ранее реализовал ALGOL 58 на более ранней машине Burroughs в течение трех месяцев своего летнего перерыва, и он был косвенно вовлечен в проектирование B5000 в качестве консультанта. Многие списывали ALGOL со счетов, ошибочно полагая, что языки высокого уровня не могут иметь ту же мощность, что и ассемблер, и, таким образом, не осознавая потенциал ALGOL как языка системного программирования.
Компилятор Burroughs ALGOL был очень быстрым — это впечатлило голландского ученого Эдсгера Дейкстру , когда он представил программу для компиляции на заводе B5000 Pasadena. Его колода карт была скомпилирована почти сразу, и он немедленно захотел несколько машин для своего университета, Эйндховенского технологического университета в Нидерландах. Компилятор был быстрым по нескольким причинам, но главной причиной было то, что это был однопроходный компилятор . Ранние компьютеры не имели достаточно памяти для хранения исходного кода, поэтому компиляторам (и даже ассемблерам) обычно требовалось читать исходный код более одного раза. Синтаксис Burroughs ALGOL, в отличие от официального языка, требует, чтобы каждая переменная (или другой объект) была объявлена до ее использования, поэтому вполне возможно написать компилятор ALGOL, который считывает данные только один раз. Эта концепция имеет глубокие теоретические последствия, но она также позволяет выполнять очень быструю компиляцию. Большие системы Burroughs могли компилировать так же быстро, как считывали исходный код с перфокарт , и у них были самые быстрые считыватели карт в отрасли.
Мощный компилятор Burroughs COBOL также был однопроходным и таким же быстрым. Программа COBOL на 4000 карт компилировалась так быстро, как считыватели со скоростью 1000 карт/минуту могли считывать код. Программа была готова к использованию, как только карты проходили через считыватель.
B6500 [7] (поставка в 1969 году [8] [9] ) и B7500 [ требуется ссылка ] были первыми компьютерами в единственной линейке систем Burroughs, сохранившимися до наших дней. Хотя они были вдохновлены B5000, они имели совершенно новую архитектуру. Среди наиболее важных отличий были
Среди других клиентов B6700 и B7700 были все пять новозеландских университетов в 1971 году. [11]
Линейка B8500 [1] [2] происходит от D825 [12] , военного компьютера, созданного на основе B5000.
B8500 был разработан в 1960-х годах как попытка объединить проекты B5500 и D825. Система использовала монолитные интегральные схемы с магнитной тонкопленочной памятью . Архитектура использовала 48-битное слово, стек и дескрипторы, как у B5500, но не рекламировалась как совместимая снизу вверх. [1] B8500 так и не удалось заставить работать надежно, и проект был отменен после 1970 года, так и не поставив законченную систему. [2]
Центральная концепция виртуальной памяти появилась в проектах Ferranti Atlas и Rice Institute Computer , а центральные концепции дескрипторов и маркированной архитектуры появились в проекте Rice Institute Computer [13] в конце 1950-х годов. Однако, даже если эти проекты оказали прямое влияние на Burroughs, архитектуры B5000, B6500 и B8500 сильно отличались от архитектур Atlas и машины Rice; они также сильно отличаются друг от друга.
Первой из больших систем Burroughs была B5000. Разработанная в 1961 году, это была вторая поколенная ЭВМ, использующая дискретную транзисторную логику и память на магнитных сердечниках , за которой последовали B5500 и B5700. Первыми машинами, заменившими архитектуру B5000, были B6500 и B7500. Машины-преемники B6500 и B7500 следовали тенденциям развития оборудования, чтобы повторно реализовать архитектуры в новой логике в течение следующих 25 лет, с B6500, B7500, B6700, B7700, B6800, B7800, B5900, [NB 4] B7900 и, наконец, Burroughs A series. После слияния, в ходе которого 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.
Проектирование, разработка и производство оборудования и программного обеспечения были разделены между двумя основными местами: в округе Ориндж, Калифорния , и на окраине Филадельфии . Первоначальный завод Large Systems, на котором были разработаны B5000 и B5500, находился в Пасадене, Калифорния , но переехал в Индастри-Сити, Калифорния , где был разработан B6500. Место в округе Ориндж, которое располагалось на заводе в Мишн-Вьехо, Калифорния, но иногда включало объекты в соседних Ирвайне и Лейк-Форесте , отвечало за меньшую линию B6x00, в то время как операции на Восточном побережье, базирующиеся в Тредиффрине, Пенсильвания , занимались большей линией B7x00. Все машины обеих линий были полностью объектно-совместимыми, то есть программа, скомпилированная на одной, могла быть выполнена на другой. Более новые и более крупные модели имели инструкции, которые не поддерживались на более старых и более медленных моделях, но оборудование, сталкиваясь с нераспознанной инструкцией, вызывало функцию операционной системы, которая ее интерпретировала. Другие различия включают в себя то, как обрабатывались переключение процессов и ввод-вывод, а также функциональность обслуживания и холодного запуска. Более крупные системы включали аппаратное планирование процессов и более мощные модули ввода-вывода, а также более высокофункциональные процессоры обслуживания. Когда модели Bxx00 были заменены моделями серии A, различия сохранились, но их уже нельзя было легко идентифицировать по номеру модели.
Большие системы Burroughs реализуют стековые архитектуры, полученные из ALGOL . B5000 была первой стековой системой.
Хотя B5000 был специально разработан для поддержки ALGOL, это была только отправная точка. Другие бизнес-ориентированные языки, такие как COBOL, также хорошо поддерживались, в частности, мощными строковыми операторами, которые были включены для разработки быстрых компиляторов.
ALGOL, используемый в B5000, является расширенным подмножеством ALGOL. Он включает мощные инструкции по обработке строк, но исключает определенные конструкции ALGOL, в частности неопределенные формальные параметры. Механизм DEFINE служит той же цели, что и #defines, найденные в C, но полностью интегрирован в язык, а не является препроцессором. Тип данных EVENT облегчает координацию между процессами, а блоки ON FAULT позволяют обрабатывать сбои программы.
Пользовательский уровень ALGOL не включает многие небезопасные конструкции, необходимые операционной системе и другому системному программному обеспечению. Два уровня языковых расширений предоставляют дополнительные конструкции: ESPOL и NEWP для написания MCP и тесно связанного программного обеспечения, а также DCALGOL и DMALGOL для предоставления более конкретных расширений для определенных видов системного программного обеспечения.
Первоначально операционная система B5000 MCP была написана на расширении расширенного ALGOL под названием ESPOL (Executive Systems Programming Oriented Language). В середине-конце 70-х годов его заменил язык NEWP . Хотя NEWP, вероятно, просто означало «Новый язык программирования», это название окружено легендами. Распространенная (возможно, апокрифическая) история в Burroughs того времени предполагала, что оно произошло от « No Executive Washroom Privileges ». Другая история заключается в том, что около 1976 года Джон МакКлинток из Burroughs (инженер-программист, разрабатывающий NEWP) назвал язык «NEWP» после того, как его снова спросили: «есть ли у него уже название»: ответив «nyoooop», он принял это в качестве названия. NEWP также был подмножеством расширения ALGOL, но он был более безопасным, чем ESPOL, и отбросил некоторые малоиспользуемые сложности ALGOL. Фактически, все небезопасные конструкции отклоняются компилятором NEWP, если только блок специально не помечен для разрешения этих инструкций. Такая маркировка блоков обеспечивает многоуровневый механизм защиты.
Программы NEWP, содержащие небезопасные конструкции, изначально неисполняемы. Администратор безопасности системы может «благословить» такие программы и сделать их исполняемыми, но обычные пользователи не могут этого сделать. (Даже «привилегированные пользователи», которые обычно имеют по сути привилегии root, могут не иметь возможности сделать это в зависимости от конфигурации, выбранной сайтом.) Хотя NEWP может использоваться для написания общих программ и имеет ряд функций, разработанных для крупных программных проектов, он не поддерживает все, что поддерживает ALGOL.
NEWP имеет ряд возможностей для реализации крупномасштабных программных проектов, таких как операционная система, включая именованные интерфейсы (функции и данные), группы интерфейсов, модули и супермодули. Модули группируют данные и функции вместе, обеспечивая легкий доступ к данным как к глобальным внутри модуля. Интерфейсы позволяют модулю импортировать и экспортировать функции и данные. Супермодули позволяют группировать модули.
В первоначальной реализации система использовала присоединенный специализированный процессор передачи данных (DCP) для обработки ввода и вывода сообщений с/на удаленные устройства. Это был 24-битный миникомпьютер с обычной архитектурой регистров и аппаратными возможностями ввода-вывода для обработки тысяч удаленных терминалов. DCP и B6500 общались с помощью сообщений в памяти, по сути пакетов в сегодняшних терминах, а MCS выполнял обработку этих сообщений на стороне B6500. В первые годы DCP имел ассемблер (Dacoma), прикладную программу под названием DCPProgen, написанную на ALGOL B6500. Позже компилятор NDL (Network Definition Language) сгенерировал код DCP и NDF (файл определения сети). В конечном счете, дальнейшее обновление привело к разработке языка и компилятора NDLII, которые использовались совместно с моделями DCP 4 и 5. Для каждого вида инструкции DCP существовала одна функция ALGOL, и если вы вызывали эту функцию, то соответствующие биты инструкции DCP выдавались на выход. Программа DCP была программой ALGOL, включающей в себя только длинный список вызовов этих функций, по одному на каждое выражение языка ассемблера. По сути, ALGOL действовал как макропроход макроассемблера. Первый проход был компилятором ALGOL; второй проход запускал полученную программу (на B6500), которая затем выдавала двоичный файл для DCP.
Начиная с начала 1980-х годов технология DCP была заменена на ICP (Integrated Communications Processor), которая обеспечивала подключение на основе локальной сети для мэйнфреймовой системы. Удаленные устройства и удаленные серверы/мэйнфреймы подключались к сети через автономные устройства, называемые CP2000. CP2000 были разработаны для обеспечения поддержки сетевых узлов в распределенной сети, где узлы были подключены с использованием сетевой технологии BNAV2 (Burroughs Network Architecture Version 2). BNAV2 был функциональным эквивалентом Burroughs продукта IBM SNA и поддерживал взаимодействие со средами IBM в транспортных режимах PUT2 и PUT5. Изменение внешнего оборудования для передачи данных не потребовало никаких изменений в существующем программном обеспечении MCS (Message Control System (обсуждается ниже)).
На входе сообщения передавались из DCP через внутреннюю шину в соответствующий стек процессов DCP MCP Datacom Control (DCC). Один процесс DCC инициировался для каждого DCP, настроенного в системе. Затем стек процессов DCP обеспечивал постановку входящего сообщения в очередь для доставки в MCS, идентифицированный для обработки трафика с конкретного исходного устройства, и возврат любого ответа в DCP для доставки на устройство назначения. С точки зрения обработки не требовалось никаких изменений в программном обеспечении MCS для обработки различных типов оборудования шлюза, будь то любой из 5 стилей DCP или комбинации ICP или ICP/CP2000.
Помимо того, что MCS является службой доставки сообщений, она представляет собой промежуточный уровень безопасности между кодом операционной системы (на NEWP) и пользовательскими программами (на ALGOL или других прикладных языках, включая COBOL, FORTRAN и, позднее, JAVA). MCS можно считать программой промежуточного программного обеспечения , которая написана на DCALGOL (Data Communications ALGOL). Как указано выше, MCS получала сообщения из очередей, поддерживаемых Datacom Control Stack (DCC), и пересылала эти сообщения в соответствующее приложение/функцию для обработки. Одной из первых MCS была CANDE (Command AND Edit), которая была разработана как среда разработки онлайн-программ. Университет Отаго в Новой Зеландии разработал тонкую среду разработки программ, эквивалентную CANDE, которую они назвали SCREAM/6700, в то же время, когда IBM предлагала удаленную службу разделения времени/разработки программ, известную как CALL/360, которая работала на системах серии IBM 360. Другая MCS под названием COMS была представлена около 1984 года и разработана как высокопроизводительная система управления обработкой транзакций. Существовали среды обработки транзакций-предшественники, включавшие GEMCOS (GEneralized Message COntrol System), а дочерняя компания австралийской компании Burroughs разработала MCS под названием TPMCS (Transaction Processing 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.
Другой вариант ALGOL — DMALGOL (Data Management ALGOL). DMALGOL — это расширенный ALGOL для компиляции программного обеспечения базы данных DMSII из файлов описания базы данных, созданных компилятором DASDL (Data Access and Structure Definition Language). Проектировщики и администраторы баз данных компилируют описания баз данных для генерации кода 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 .
В последующие годы, когда размер кода компилятора стал менее важным, большинство конструкций предварительной обработки стали доступны на пользовательском уровне ALGOL. Только небезопасные конструкции и прямая обработка файла описания базы данных остаются ограниченными DMALGOL.
Во многих ранних системах и языках программистам часто говорили не делать свои процедуры слишком маленькими. Вызовы процедур и возвраты были дорогими, поскольку для поддержания стека приходилось выполнять ряд операций. B5000 был разработан как стековая машина — все данные программы, за исключением массивов (которые включают строки и объекты), хранились в стеке. Это означало, что стековые операции были оптимизированы для эффективности. Как стекоориентированная машина, она не имеет программно адресуемых регистров.
Многозадачность также очень эффективна на линиях B5000 и B6500. Существуют специальные инструкции для выполнения переключений процессов:
Каждый стек и связанная с ним [NB 5] Таблица ссылок на программы (PRT) представляет собой процесс (задачу или поток), и задачи могут блокироваться в ожидании запросов ресурсов (включая ожидание запуска процессора, если задача была прервана из-за вытесняющей многозадачности). Пользовательские программы не могут выдавать IP1, [NB 5] IP2 [NB 5] или MVST, [NB 6], и в операционной системе есть только одно место, где это делается.
Итак, переключение процессов происходит примерно так: процесс запрашивает ресурс, который не доступен немедленно, возможно, чтение записи файла из блока, который в данный момент не находится в памяти, или системный таймер вызвал прерывание. Код операционной системы вводится и запускается поверх пользовательского стека. Он отключает таймеры пользовательских процессов. Текущий процесс помещается в соответствующую очередь для запрашиваемого ресурса или в очередь готовности, ожидающую процессора, если это упреждающее переключение контекста. Операционная система определяет первый процесс в очереди готовности и вызывает инструкцию move_stack, которая делает процесс во главе очереди готовности активным.
Производительность стека считалась низкой по сравнению с архитектурами на основе регистров, например, такая архитектура рассматривалась и была отклонена для System/360 . [24] Один из способов увеличить скорость системы — хранить данные как можно ближе к процессору. В стеке B5000 это было сделано путем назначения двух верхних позиций стека двум регистрам A и B. Большинство операций выполняется на этих двух верхних позициях стека. На более быстрых машинах после B5000 большая часть стека может храниться в регистрах или кэше рядом с процессором.
Таким образом, проектировщики нынешних преемников систем B5000 могут оптимизировать любую новейшую технологию, а программистам не нужно корректировать свой код, чтобы он работал быстрее – им даже не нужно перекомпилировать, тем самым защищая инвестиции в программное обеспечение. Известно, что некоторые программы работают годами при многих обновлениях процессора. Такое ускорение ограничено на регистровых машинах. [ необходима цитата ]
Другим аргументом в пользу скорости, продвигаемым разработчиками RISC, было то, что скорость процессора значительно выше, если все находится на одном кристалле. Это было обоснованным аргументом в 1970-х годах, когда более сложные архитектуры, такие как B5000, требовали слишком много транзисторов для размещения на одном кристалле. Однако сегодня это не так, и каждая машина-преемница B5000 теперь размещается на одном кристалле, как и методы поддержки производительности, такие как кэши и конвейеры инструкций.
Фактически, линейка A Series последователей B5000 включала первый однокристальный мейнфрейм, 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 — — — — — — — — — — — — — — — — — — — real 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 (межпроцессного взаимодействия). Поскольку две или более задач теперь имеют доступ к общим переменным, задачи должны быть синхронизированы для предотвращения условий гонки, что обрабатывается типом данных EVENT, где процессы могут ЖДАТЬ одного или нескольких событий, пока оно не будет вызвано другим сотрудничающим процессом. EVENT также допускают синхронизацию взаимного исключения через функции PROCURE и LIBERATE. Если по какой-либо причине дочерняя задача умирает, вызывающая задача может продолжиться, однако, если родительский процесс умирает, то все дочерние процессы автоматически завершаются. На машине с более чем одним процессором процессы могут выполняться одновременно. Этот механизм EVENT является базовым средством для многопроцессорной обработки в дополнение к многозадачности.
Последний тип вызова — run . Он запускает процедуру как независимую задачу, которая может продолжаться после завершения исходного процесса. По этой причине дочерний процесс не может получить доступ к переменным в родительской среде, и все параметры, передаваемые вызываемой процедуре, должны быть вызваны по значению.
Таким образом, Burroughs Extended ALGOL имел некоторые из функций многопроцессорности и синхронизации более поздних языков, таких как Ada . Он использовал поддержку асинхронных процессов, встроенную в оборудование.
Последняя возможность заключается в том, что в NEWP процедура может быть объявлена INLINE , то есть когда компилятор видит ссылку на нее, код для процедуры генерируется 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 | n | (4, 1) Целое число n (объявляется при входе в блок, а не в процедуру)|-----------------------|| D[4]==>3 | MSCW | (4, 0) Управляющее слово стека меток, содержащее ссылку на 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) Управляющее слово стека меток, содержащее ссылку на D[2].|========================|| 1 | a | (2, 7) Массив a ======>[блок памяти из десяти слов]|-----------------------|| 0 | g | (2, 6) Реальное g |-----------------------|| 0 | f | (2, 5) Реальное f |-----------------------|| 0 | k | (2, 4) Целое число k |-----------------------|| 0 | j | (2, 3) Целое число j |-----------------------|| 0 | i | (2, 2) Целое число i|-----------------------|| 3 | RCW | (2, 1) Возврат контрольного слова|-----------------------|| D[2]==>3 | MSCW | (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] во время операций ввода-вывода. В начале девяностых эта возможность была реализована как языковая функция как STRUCTURE BLOCKs и – в сочетании с библиотечной технологией – как CONNECTION BLOCKs. Возможность связывать структуру данных с областью адреса регистра отображения реализовала объектную ориентацию. Таким образом, B6500 фактически использовал форму объектной ориентации задолго до того, как этот термин был когда-либо использован.
В других системах компилятор мог бы построить свою таблицу символов аналогичным образом, но в конечном итоге требования к хранению были бы сопоставлены, и машинный код был бы написан для использования плоских адресов памяти 16-бит или 32-бит или даже 64-бит. Эти адреса могли бы содержать что угодно, так что запись по неправильному адресу могла бы повредить что угодно. Вместо этого двухкомпонентная схема адресации была реализована аппаратно. На каждом лексическом уровне переменные размещались со смещениями вверх от основания стека уровня, обычно занимая одно слово — переменные двойной точности или комплексные переменные занимали бы два. Массивы не хранились в этой области, хранился только однословный дескриптор для массива. Таким образом, на каждом лексическом уровне общие требования к хранению были невелики: десятки, сотни или несколько тысяч в крайних случаях, определенно не количество, требующее 32 бит или больше. И действительно, это было отражено в форме инструкции VALC (вызов значения), которая загружала операнд в стек. Этот код операции был длиной в два бита, а остальная часть битов байта была объединена со следующим байтом, чтобы получить четырнадцатибитное поле адресации. Выполняемый код будет на некотором лексическом уровне, скажем, шесть: это означало, что только лексические уровни с нуля по шесть были допустимы, и поэтому для указания желаемого лексического уровня требовалось всего три бита. Таким образом, адресная часть операции VALC зарезервировала для этой цели всего три бита, а оставшиеся были доступны для ссылки на сущности на этом и более низких уровнях. Глубоко вложенная процедура (то есть на высоком лексическом уровне) имела бы меньше битов, доступных для идентификации сущностей: для уровня шестнадцать и выше потребовалось бы пять битов для указания выбора уровней 0–31, таким образом, оставляя девять бит для идентификации не более первых 512 сущностей любого лексического уровня. Это намного компактнее, чем адресация сущностей по их буквальному адресу памяти в 32-битном адресном пространстве. Кроме того, данные загружал только код операции VALC: коды операций ADD, MULT и т. д. не выполняли адресацию, работая исключительно с верхними элементами стека.
Гораздо важнее то, что этот метод означал, что многие ошибки, возможные в системах, использующих плоскую адресацию, не могли произойти, потому что они были просто невыразимы даже на уровне машинного кода. Задача не имела возможности повредить память, используемую другой задачей, потому что она не имела возможности разработать свой адрес. Смещения от указанного D-регистра проверялись оборудованием по границе стекового кадра: неверные значения были бы перехвачены. Аналогично, внутри задачи дескриптор массива содержал информацию о границах массива, и поэтому любая операция индексации проверялась оборудованием: другими словами, каждый массив формировал свое собственное адресное пространство. В любом случае, маркировка всех слов памяти обеспечивала второй уровень защиты: неправильно направленное назначение значения могло перейти только в место хранения данных, а не в то, которое содержало указатель или дескриптор массива и т. д., и уж тем более не в место хранения машинного кода.
Массивы не хранились в памяти смежно с другими переменными, им каждому предоставлялось собственное адресное пространство, которое находилось через дескриптор. Механизм доступа заключался в вычислении на стеке индексной переменной (которая, следовательно, имела полный потенциал диапазона целых чисел, а не только четырнадцать бит) и использовании ее в качестве смещения в адресном пространстве массива с проверкой границ, предоставляемой оборудованием. По умолчанию, если длина массива превышала 1024 слова, массив сегментировался, а индекс преобразовывался в индекс сегмента и смещение в индексированный сегмент. Однако существовала возможность предотвратить сегментацию, указав массив как LONG в объявлении. В случае ALGOL многомерный массив использовал бы несколько уровней такой адресации. Для ссылки на A[i,j] первый индекс был бы в массиве дескрипторов, по одному дескриптору для каждой из строк A, которая затем индексировалась бы с помощью j, как для одномерного массива, и так далее для более высоких измерений. Аппаратная проверка известных границ всех индексов массива позволит предотвратить ошибочную индексацию.
Однако FORTRAN рассматривает все многомерные массивы как эквивалентные одномерному массиву того же размера, и для многомерного массива простая целочисленная арифметика используется для вычисления смещения, где элемент A[i,j,k] будет найден в этой одиночной последовательности. Одномерный эквивалентный массив, возможно сегментированный, если он достаточно большой, затем будет доступен так же, как одномерный массив в ALGOL. Хотя доступ за пределы этого массива будет предотвращен, неправильное значение для одного индекса в сочетании с соответствующим образом неправильным значением для другого индекса может не привести к нарушению границ одиночного массива последовательности; другими словами, индексы не проверялись по отдельности.
Поскольку хранилище массива не было ограничено с каждой стороны хранилищем для других элементов, системе было легко «изменить размер» массива — хотя изменение количества измерений было исключено, поскольку компиляторы требовали, чтобы все ссылки имели одинаковое количество измерений. В случае ALGOL это позволило разработать «рваные» массивы, а не обычные фиксированные прямоугольные (или массивы большей размерности). Таким образом, в двух измерениях рваный массив будет иметь строки разного размера. Например, если задан большой массив A[100,100] из в основном нулевых значений, то представление разреженного массива, объявленное как SA[100,0], может иметь каждую строку, измененную так, чтобы иметь ровно столько элементов, чтобы хранить только ненулевые значения A вдоль этой строки.
Поскольку массивы размером более 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 также могут быть запрошены.
В предыдущем обсуждении для описания объявлений ARRAY использовалась реализация синтаксиса ALGOL, но та же функциональность поддерживается в COBOL и FORTRAN.
Одной из приятных особенностей структуры стека является то, что если программа действительно дает сбой, то делается дамп стека, и программисту очень легко узнать, в каком именно состоянии была запущенная программа. Сравните это с дампами ядра и пакетами обмена других систем.
Еще одна вещь о структуре стека заключается в том, что программы неявно рекурсивны. От FORTRAN не ожидалось поддержки рекурсии, и, возможно, одним из камней преткновения для понимания людьми того, как должен был быть реализован ALGOL, было то, как реализовать рекурсию. На B5000 это не было проблемой — на самом деле, у них была обратная проблема, как сделать так, чтобы программы не были рекурсивными. В конце концов, они не стали этим заморачиваться. Компилятор FORTRAN от Burroughs допускал рекурсивные вызовы (как и любой другой компилятор FORTRAN), но, в отличие от многих других компьютеров, в системе на основе стека возвраты из таких вызовов также были успешными. Это могло иметь странные эффекты, как в случае с системой для формальной обработки математических выражений, чьи центральные подпрограммы многократно вызывали друг друга, не возвращаясь: большие задания завершались переполнением стека!
Таким образом, у FORTRAN от Burroughs была лучшая проверка ошибок, чем у других современных реализаций FORTRAN. [ требуется ссылка ] Например, для подпрограмм и функций он проверял, что они были вызваны с правильным количеством параметров, как это обычно бывает у компиляторов в стиле ALGOL. На других компьютерах такие несоответствия были распространенной причиной сбоев. Аналогично с проверкой привязки к массиву: программы, которые годами использовались на других системах, смущающе часто давали сбой при запуске на системе Burroughs. Фактически, Burroughs стал известен своими превосходными компиляторами и реализацией языков, включая объектно-ориентированный Simula (надмножество ALGOL), и Айверсон , разработчик APL, заявил, что реализация APL от Burroughs была лучшей из тех, что он видел. [ необходима цитата ] Джон Маккарти , разработчик языка LISP , не согласился, поскольку LISP был основан на модифицируемом коде [ необходима цитата ] , ему не нравился неизменяемый код B5000 [ необходима цитата ] , но большинство реализаций LISP в любом случае работали бы в интерпретируемой среде.
Хранилище, необходимое для нескольких процессов, поступало из пула памяти системы по мере необходимости. Не было необходимости выполнять SYSGEN в системах Burroughs, как в конкурирующих системах, чтобы предварительно настроить разделы памяти для запуска задач.
Наиболее определяющим аспектом B5000 является то, что это стековая машина, как описано выше. Однако две другие очень важные особенности архитектуры заключаются в том, что она основана на тегах и дескрипторах.
В оригинальном B5000 бит флага в каждом управляющем или числовом слове [NB 7] был отведен для идентификации слова как управляющего или числового слова. Это было частично механизмом безопасности, чтобы не дать программам испортить управляющие слова в стеке.
Позже, когда был разработан B6500, было решено, что 1-битное контрольное слово/числовое различие было мощной идеей, и это было расширено до трех бит за пределами 48-битного слова в теге. Биты данных - это биты 0-47, а тег находится в битах 48-50. Бит 48 был битом только для чтения, таким образом, нечетные теги указывали контрольные слова, которые не могли быть записаны программой уровня пользователя. Кодовым словам был присвоен тег 3. Вот список тегов и их функции:
Внутренне некоторые машины имели 60-битные слова, а дополнительные биты использовались в инженерных целях, таких как поле исправления ошибок кода Хэмминга , но программисты их никогда не видели.
Текущее воплощение этих машин, Unisys ClearPath, расширило теги еще больше до четырехбитного тега. Уровень микрокода, который определял четырехбитные теги, назывался уровнем Gamma.
Слова с четными тегами — это пользовательские данные, которые могут быть изменены пользовательской программой как пользовательское состояние. Слова с нечетными тегами создаются и используются непосредственно оборудованием и представляют состояние выполнения программы. Поскольку эти слова создаются и используются определенными инструкциями или оборудованием, точный формат этих слов может меняться между аппаратной реализацией, и пользовательским программам не нужно перекомпилировать, поскольку тот же поток кода будет выдавать те же результаты, даже если системный формат слова мог измениться.
Слова тега 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.
На рисунке слева показано, что архитектура больших систем Burroughs по сути своей является аппаратной архитектурой для объектно-ориентированного программирования , чего до сих пор не существует в традиционных архитектурах.
Для больших систем Burroughs существует три различных набора инструкций. Все три основаны на коротких слогах , которые равномерно вписываются в слова.
Программы на B5000, B5500 и B5700 состоят из 12-битных слогов , по четыре в слове. Архитектура имеет два режима, режим слов и режим символов, и каждый имеет отдельный репертуар слогов. Процессор может быть либо в состоянии управления, либо в нормальном состоянии, и некоторые слоги допустимы только в состоянии управления. Архитектура не предусматривает адресации регистров или хранилища напрямую; все ссылки осуществляются через таблицу ссылок на программы из 1024 слов, текущий сегмент кода, отмеченные местоположения в стеке или к регистрам A и B, содержащим два верхних местоположения в стеке. Burroughs нумерует биты в слоге от 0 (старший бит) до 11 (младший бит)
Программы состоят из 8-битных слогов , которые могут быть Name Call, Value Call или образовывать оператор, который может быть длиной от одного до двенадцати слогов. Существует менее 200 операторов , все из которых укладываются в 8-битные слоги. Многие из этих операторов являются полиморфными в зависимости от типа данных, с которыми действуют, как указано в теге. Если мы проигнорируем мощные операторы сканирования, передачи и редактирования строк, то базовый набор составит всего около 120 операторов. Если мы удалим операторы, зарезервированные для операционной системы, такие как MVST и HALT, то набор операторов, обычно используемых программами уровня пользователя, составит менее 100. Слоги Name Call и Value Call содержат пары адресов; слоги Operator либо не используют адреса, либо используют управляющие слова и дескрипторы в стеке.
Линия B5000 также была пионером в использовании двух процессоров, соединенных вместе на высокоскоростной шине в качестве ведущего и ведомого. В линиях B6000, B7000 и B8000 процессоры были симметричными. Линия B7000 могла иметь до восьми процессоров, при условии, что хотя бы один был модулем ввода-вывода. RDLK (ReaD с LocK) — это очень низкоуровневый способ синхронизации между процессорами. RDLK работает в одном цикле. Механизм более высокого уровня, обычно используемый пользовательскими программами, — это тип данных EVENT . Тип данных EVENT имел некоторые системные накладные расходы. Чтобы избежать этих накладных расходов, можно использовать специальную технику блокировки, называемую блокировками Dahm (названную в честь гуру программного обеспечения Burroughs, Дэйва Дама). Блокировки Dahm использовали оператор языка READLOCK ALGOL, который генерировал оператор RDLK на уровне кода.
Известные операторы:
HEYU — отправить прерывание другому процессору
RDLK — оператор семафора низкого уровня: загрузить регистр A с адресом памяти, заданным регистром A, и поместить значение в регистр B в этом адресе памяти в одном непрерывном цикле. Компилятор Algol создал код для вызова этого оператора с помощью специальной функции, которая позволяла выполнять операцию «обмена» для данных из одного слова без явного временного значения. x:=RDLK(x,y);
WHOI — идентификация процессора
IDLE — простаивать до получения прерывания
Два процессора могли изредка одновременно посылать друг другу команду «HEYU», что приводило к блокировке, известной как « смертельные объятия ».
Прямое влияние B5000 можно увидеть в текущей линейке мэйнфреймов Unisys ClearPath, которые являются прямыми потомками B6500, на которую повлиял B5000, и которые до сих пор имеют операционную систему MCP после 40 лет последовательной разработки. Эта архитектура теперь называется emode (для режима эмуляции), поскольку архитектура B6500 была реализована на машинах, построенных на процессорах Intel Xeon, работающих с набором инструкций x86 в качестве собственного набора инструкций, с кодом, работающим на этих процессорах, эмулирующим набор инструкций B5000. В этих машинах также должен был быть nmode ( собственный режим ), но он был исключен [ нужна цитата ] , поэтому вы часто можете слышать, как машины-преемники B6500 называют «машинами emode».
Машины B5000 программировались исключительно на языках высокого уровня; ассемблер не использовался.
Архитектура стека B5000 вдохновила Чака Мура , разработчика языка программирования Forth , который столкнулся с B5500 во время учебы в Массачусетском технологическом институте. В книге Forth - The Early Years Мур описал это влияние, отметив, что DUP, DROP и SWAP в Forth произошли от соответствующих инструкций B5500 (DUPL, DLET, EXCH).
Машины B5000 с их стековой архитектурой и тегированной памятью также оказали сильное влияние на советскую серию мэйнфреймов и суперкомпьютеров Эльбрус . Первые два поколения серии имели тегированную память и стековые процессоры, которые программировались только на языках высокого уровня. Для них существовал своего рода язык ассемблера , называемый Эль-76, но он был более или менее модификацией АЛГОЛА 68 и поддерживал структурное программирование и первоклассные процедуры. Однако более поздние поколения серии перешли от этой архитектуры к EPIC -подобным VLIW-процессорам .
Разработчики бизнес-системы HP 3000 компании Hewlett -Packard использовали 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 была единственной управляющей программой, но поддержка, предоставляемая этими машинами, все еще уступает той, которая предоставлялась на машинах, где набор инструкций B6500 является собственным набором инструкций. Малоизвестная архитектура процессоров Intel, которая фактически предшествовала 32-разрядным реализациям набора инструкций x86, Intel iAPX 432 , могла бы обеспечить эквивалентную физическую основу, поскольку она также была по сути объектно-ориентированной архитектурой.