Блок регистров процессора ЕС-2020 — «виртуальная» сущность, к которой отнесена большая часть аппаратных регистров, разделяемых на адресные, общие и служебные. Кроме них, в состав процессора входит ряд узкоспециализированных регистров, часть из которых уже встречалась в предыдущих публикациях (РАПП, РМК, РМН, РНЗ, РБЗ), а другая ещё встретится.
Адресные регистры
Архитектура Системы 360 предусматривает 24-разрядный адрес памяти; физически в конкретной реализации ширина адреса может быть меньше — скажем, 16 разрядов в IBMовской модели 30 или 18 разрядов в ЕС-1020, но с точки зрения программы он всегда 24-разрядный. Кроме того, архитектура требует обнаруживать обращения по недопустимым адресам (лежащим выше физически имеющегося объёма памяти), при этом возникает особый случай адресации, приводящий к программному прерыванию, — с его обнаружением, выполняемым аппаратно, мы познакомились в предыдущей статье.
В процессе выполнения команд процессору приходится иметь дело с адресами самих команд и адресами операндов, причём в основной памяти (ОП) может находиться один или два операнда. Кроме того, микропрограмме постоянно требуется обращаться к локальной памяти (ЛП), поскольку там хранится содержимое программно доступных регистров (общего назначения, с плавающей запятой и PSW) и расположены рабочие ячейки, требующиеся для хранения промежуточных результатов во время выполнения сложных команд. Соответственно, для более-менее эффективной работы процессор должен иметь несколько адресных регистров, однако, поскольку младшая модель должна быть как можно более дешёвой, а производительность не является приоритетом, их число должно быть минимальным.
Разработчики процессора ЕС-2020 остановились на трёх полноценных адресных регистрах РМФЕ, РГРИ и РПТУ, что позволяет достаточно эффективно выполнять большинство команд; они уже упоминались в предыдущей статье. Кроме того, в роли адресного, но только для доступа к ЛП, может выступать один из общих регистров, о чём будет сказано в ниже. Заметим также, что название «адресные регистры» лишь указывает на их основное назначение, но при выполнении микропрограмм они могут использоваться и для временного хранения обрабатываемых данных — собственно, это и имеет место на практике.
Поскольку физический адрес является 18-разрядным, а внутренние потоки данных имеют ширину в один байт, каждый адресный регистр является составным и делится на три независимых регистра: РМФЕ состоит из регистров РМ, РФ, РЕ; РГРИ — из РГ, РР и РИ; РПТУ — из РП, РТ и РУ.
Два младших регистра каждого из составных адресных регистров (РФ, РЕ, РР, РИ, РТ, РУ) являются полноценными 8-разрядными регистрами; технически они содержат восемь информационных разрядов и один контрольный.
Каждый из старших регистров (РМ, РГ и РП) реализован довольно необычно. Стремясь сократить количество аппаратуры, разработчики реализовали в них только три информационных бита и не стали снабжать контрольным разрядом. При записи информации в любой из этих регистров, что всегда осуществляется в выхода арифметико-логического блока (БА), младшие два бита результата операции (6:7) помещаются обычным образом в младшие биты регистра, а вот биты 0:5 результата объединяются операцией ИЛИ и записываются в бит 5 регистра, называемый уплотнённым. В результате получается, что, если при вычислении 24-разрядного адреса он вышел за пределы 18 разрядов физического адреса, т. е. если в хотя бы одном из старших шести разрядов адреса имеется единица, уплотнённый бит адресного регистра будет установлен — и при попытке доступа к памяти будет обнаружен особый случай адресации, как описывалось в предыдущей статье.
Из описания известно, что занесение в любой из девяти регистров выполняется только с выхода БА под управлением поля С микрокоманды по тактовому импульсу ТИ4 — т. е. в конце такта, когда операция в БА уже завершена и результаты достигли остальных частей процессора. Судя по функциональным схемам из [1], сканы которых будут приведены ниже, все адресные и общие регистры принимают информацию по одному лишь управляющему сигналу, например, РМ:=С; тактовый сигнал на схемах отсутствует. В то же время в схемах служебных регистров, а также в приведённых в предыдущей статье схемах регистра данных оперативной памяти РНЗ тактовый сигнал показан явным образом наряду с сигналом разрешения приёма информации, например, РБК:=С. Можно предположить, что дешифратор поля С является «полуимпульсным»: часть его выходов, управляющая занесением в адресные и общие регистры, дополнительно стробируется тактовым сигналом ТИ4, т. е. для появления на них сигнала необходимо не только наличие соответствующего кода в поле С, но и подача на дешифратор тактового импульса ТИ4 (типовая схема импульсного дешифратора, применяемого в ЕС-1020, была приведена в одной из предыдущих статей). Остальные выходы дешифратора являются обычными и активируются при наличии в поле С соответствующего кода независимо от наличия тактового импульса. Различные подходы к управлению приёмом в разные регистры можно объяснить тем, что в адресные и общие регистры информация попадает только и исключительно с выхода БА, в то время как многие разряды служебных регистров имеют также аппаратное управление, работающее «в обход» приёма информации с БА и использующее другие синхроимпульсы (наиболее хорошо это видно на примере регистра РМН, имеющего весьма сложное управление; его схемы были приведены в предыдущей статье).
Регистр РМФЕ обычно содержит адрес команды. В некоторых ситуациях его требуется освободить для использования в иных целях; в таком случае его содержимое переписывается в ячейки 8D–8F локальной памяти (они содержат младшие три байта PSW — как раз те, где, согласно архитектуре Системы 360, должен находиться адрес команды). В качестве индикатора местонахождения этого адреса используется триггер адреса команды ТАК: он сброшен, если адрес находится в РМФЕ, и установлен при его нахождении в ЛП. Этот триггер устанавливается и сбрасывается соответствующими микрооперациями поля УСТАНОВ и может быть проанализирован микрооперацией поля УСЛ0.
Содержимое регистра РМ может быть передано в БА на вход А (сигнал РА:=РМ), при этом из трёх его битов формируется контрольный разряд, служащий в данном случае лишь для проверки правильности передачи информации от регистра на вход БА, но не для контроля правильности хранения информации в самом регистре РМ. Разряды 0:4 входа А при приёме из РМ будут равны нулю.
Содержимое регистров РФ и РЕ может быть передано в БА на вход В (сигналы РВ:=РФ и РВ:=РЕ). Поскольку это полноценные 8-разрядные регистры с контрольными разрядами, последние передаются наравне с информационными битами.
Всё содержимое РМФЕ может быть по сигналу РМН:=РМФЕ (вырабатывается дешифратором поля АДРЕС) передано в адресный регистр памяти РМН, описанный в предыдущей статье. При такой передаче младшие 18 битов РМФЕ содержат адрес доступа, а установленный старший бит РМФЕ, т. е. РМ[5], служит индикатором попытки обращения к несуществующей ячейке ОП и вызовет особый случай адресации. Для битов РМ[6:7] формируется контрольный разряд, передаваемый вместе с ними в РМН. Вероятно, технически схема формирования этого разряда является частью формирования контрольного разряда для всех трёх битов РМ.
Функциональная схема РМФЕ приведена на рисунке.
Регистр РГРИ обычно содержит адрес одного из операндов. Приём информации с выхода БА в составляющие его регистры выполняется полностью аналогично регистру РМФЕ. В отличие от РМФЕ, содержимое РР и РИ может быть передано на любой из входов БА, а не только на вход В (РГ передаётся только на вход А аналогично передаче РМ).
Ещё одним отличием этого регистра от РМФЕ является возможность использования для адресации не только всего его содержимого, но и одного лишь регистра РР — этот способ используется в случае, если необходим доступ не к основной, а к локальной памяти, имеющей объём 256 байт; РР передаётся в младший байт РМН по сигналу РМН:=РР (для передачи всего содержимого РГРИ в РМН используется сигнал РМН:=РГРИ).
Наконец, младшие 13 битов РГРИ могут загружаться в регистр адреса постоянной памяти РАПП, обеспечивая переход на соответствующую микрокоманду. Эта возможность используется, по всей вероятности, только в диагностических микропрограммах.
Регистр РПТУ в плане обмена с БА подобен регистру РГРИ, но отличается от него тем, что не может применяться для загрузки РАПП. Для адресации ЛП может использоваться входящий в его состав регистр РТ.
Схема регистров РГРИ и РПТУ показана на рисунке.
Общие регистры
Общие регистры РЛ и РД имеют по восемь информационных и одному контрольному разряду и предназначены для хранения байтов данных, обрабатываемых микрокомандами, для чего содержимое РЛ и РД может подаваться на оба входа БА, а результат операции с выхода БА — приниматься в любой из этих регистров. Кроме того, регистр РД может использоваться для адресации локальной памяти подобно регистрам РР и РТ.
Схема регистров РЛ и РД приведена на рисунке. Можно заметить, что на ней допущена ошибка в нумерации разрядов регистра РМН, младший байт которого может принимать адрес обращения к ЛП из регистра РД по сигналу РМН:=РД: в отличие от подавляющего большинства других регистров машины, биты РМН нумеруются справа налево; соответственно, биты РД[0:7] заносятся в биты РМН[7:0], а не РМН[0:7].
Служебные регистры
К служебным относят шесть регистров: РБК, РБР, РБС, РБД, РБЗ и РО. Регистр РБЗ относится к блоку защиты памяти и был рассмотрен в предыдущей публикации, а РО является регистром ошибок, и о нём речь будет идти в отдельной статье. Остальные четыре регистра этой группы описываются ниже.
Поскольку служебные регистры являются, по сути, наборами триггеров, устанавливаемых и сбрасываемых независимо друг от друга частично микропрограммными, а частично аппаратными средствами, контрольных разрядов они не имеют. При передаче содержимого этих регистров в БА производится формирование контрольного бита, соответствующего передаваемому содержимому, что обеспечивает контроль правильности передачи. Надёжность хранения информации в этих регистрах никак не контролируется (в силу специфики этих регистров её можно было бы обеспечить, главным образом, путём дублирования триггеров; вероятно, разработчики посчитали такое расточительство аппаратных ресурсов неоправданным).
Регистр РБК хранит запросы внешних прерываний, их порядок в его разрядах соответствует порядку битов в коде внешнего прерывания, сохраняемого в составе старого PSW при вызове обработчика прерывания (чему будет посвящена отдельная статья):
бит 0 хранит запрос на прерывание от интервального таймера;
бит 1 хранит запрос на прерывание от кнопки на пульте управления;
биты 2:7 хранят запросы, поступающие по линиям прямого управления.
Установка триггеров РБК, кроме бита 0, производится соответствующими аппаратными сигналами. Бит 0 (запрос от таймера) устанавливается микропрограммно путём приёма в РБК информации с выхода БА подобно записи в общие и адресные регистры; этим же путём триггеры обнуляются, что происходит при вызове обработчика внешнего прерывания или при сбросе.
Содержимое РБК может быть подано на вход А БА.
Литература умалчивает о том, как «разруливается» одновременная микропрограммная запись в регистр и поступление аппаратных запросов прерываний, но очевидно, что во избежание потери прерываний необходимо, чтобы наличие запроса устанавливало соответствующий триггер даже в случае, если микропрограмма пытается записать в этот разряд нуль.
Функциональная схема регистра РБК приведена на рисунке.
В нижней части схемы показана передача информации из регистра РБК на вход А БА. Обращает на себя внимание передача через элемент И, управляемый двумя входами — сигналом РА:=РБК, поступающим с дешифратора поля А микрокоманды, и тактовым сигналом ТИ1. Эта часть схемы, на самом деле, относится уже не к регистру РБК как таковому, а к мультиплексору входа А и следующему за ним регистру РА, входящим в состав БА, — их мы увидим в следующей статье.
Регистр РБР содержит так называемую маску системы (маски прерываний, содержащиеся, с точки зрения программиста, в старшем байте PSW; применительно к ЕС-1020 это маски запросов прерываний от мультиплексного и двух селекторных каналов и маска внешних прерываний — всего четыре бита; у более мощных машин имеется большее число каналов, и маска системы может содержать до восьми битов — по биту на канал плюс бит маски внешних прерываний), маску прерываний от схем контроля машины (с точки зрения программиста, находится во втором байте PSW) и биты запросов прерываний от каналов (ещё три бита). Каждый из разрядов РБР является отдельным триггером, имеющим, помимо номера в регистре, ещё и собственное обозначение:
бит 0, ТМКМ — маска прерываний мультиплексного канала, соответствует биту PSW[0];
бит 1, ТМКС1 — маска прерываний селекторного канала № 1, соответствует биту PSW[1];
бит 2, ТМКС2 — маска прерываний селекторного канала № 2, соответствует биту PSW[2];
бит 3, ТЗПРВКМ — триггер запроса прерывания от мультиплексного канала;
бит 4, ТЗПРВКС1 — триггер запроса прерывания от селекторного канала № 1;
бит 5, ТМКТРМ — маска прерываний от схем контроля машины, соответствует биту PSW[13];
бит 6, ТЗПРВКС2 — триггер запроса прерывания от селекторного канала № 2;
бит 7, ТМПРВВ — маска внешних прерываний, соответствует биту PSW[7].
Единичное значение бита маски разрешает соответствующее прерывание, единичное состояние триггера запроса говорит о наличии этого запроса.
Заметим, что биты масок расположены таким образом, что при «сборке» или «разборке» PSW не требуется выполнять операции сдвига, достаточно логических операций, что ускоряет работу соответствующих микропрограмм.
Все восемь разрядов могут меняться микропрограммно путём обычной записи в регистр с выхода БА (сигнал РБР:=С при наличии тактового импульса ТИ4). Кроме того, триггеры запросов прерываний от селекторных каналов могут устанавливаться аппаратно, хотя и в процессе выполнения микропрограммы: такая установка происходит при записи результата операции БА в регистр РРА селекторного канала (сигнал РРА:=С; подробно каналы будут обсуждаться отдельно, здесь же заметим, что аппаратура определяет, с каким из двух каналов работает микропрограмма, по состоянию битов регистра РБС, который будет описан чуть ниже).
Содержимое РБР может быть подано на вход В БА.
Схема регистра РБР приведена на рисунке.
Регистр РБС содержит различные индикаторы:
биты 0 и 1 отражают особые случаи соответственно адресации и защиты, т. е. попытки микропрограммно обратиться к отсутствующей или защищённой ключом области ОП;
биты 2:5 выбирают, с каким набором «дополнительных» регистров (РР0—РР9, РРА—РРЕ) идёт работа — с регистрами пульта управления, КС2, КС1 или КМ соответственно;
биты 6:7 обычно хранят код условия, соответствуя при этом, с точки зрения программиста, разрядам PSW[34:35].
Все триггеры регистра РБС меняют своё состояние по тактовому импульсу ТИ4. Информация в них может обычным образом приниматься с выхода БА, однако предусмотрены и альтернативные способы установки.
Биты 0 и 1 отражают особые случаи, возникающие при обращениях к основной памяти или памяти ключей, поэтому при обнаружении аппаратурой любого из них происходит установка соответствующего триггера, как описывалось в предыдущей статье. Когда один из них установлен, при определённых условиях выполнение текущей микропрограммы может быть прервано для вызова микропрограммы обработки особых случаев; подробнее об этом будет рассказано в статье, посвящённой прерываниям.
Биты 2:5 могут устанавливаться и сбрасываться соответствующими микрооперациями поля УСТАНОВ (0БС2, 1БС2 и т. д.). В процессе выполнения микропрограмм, реализующих систему команд процессора, они выполняют роль флажков, отражающих текущее состояние микропрограммы, и лишь при работе с каналами и пультом управления их назначение строго определено (при выполнении микрокоманд, обращающихся к одному из «дополнительных» регистров, один из этих битов должен быть установлен, а все остальные должны быть сброшены).
Наконец, биты 6:7, как было сказано, обычно хранят код условия, видимый программисту через PSW и анализируемый командами условного перехода BC и BCR. Соответственно, на момент завершения микропрограммы реализации некоторой команды они должны находиться в состоянии, отражающем код условия, и не должны модифицироваться микропрограммами реализации команд, не изменяющих код условия (например, командами загрузки значения из памяти в регистр или записи значения из регистра в память — L, LH, ST, STH и некоторыми другими). Однако микропрограммы команд, изменяющих код условия, могут использовать эти биты в качестве рабочих флажков; лишь в конце своего выполнения они должны присваивать этим битам значение кода условия.
Правила установки кода условия отличаются для разных команд, однако некоторые часто используемые команды используют идентичные правила. Специально для ускорения микропрограмм реализации этих команд предусмотрены два значения поля УСТАНОВ — КУ1 и КУ2.
При наличии микрооперации КУ1, соответствующей командам сложения и вычитания целых чисел со знаком, биты РБС[6:7] принимают следующие значения:
00, если триггеры ТРКФ и ТПЕР сброшены, что соответствует нулевому результату выполнения в АЛУ косвенной функции;
01, если ТРКФ и ТЗН установлены, а ТПЕР сброшен (отрицательный результат);
10, если ТРКФ установлен, а ТЗН и ТПЕР сброшены (положительный результат);
11, если установлен триггер ТПЕР, т. е. если возникло переполнение.
При наличии микрооперации КУ2 установка битов РБС[6:7] соответствует операциям сложения и вычитания чисел без знака: в РБС[6] заносится значение триггера ТПКФ (он устанавливается, когда при выполнении косвенной функции возникает перенос), а в РБС[7] — триггера ТРКФ (он устанавливается, когда результат косвенной функции отличен от нуля).
Все перечисленные выше триггеры являются частью БА и будут описаны в следующей статье.
Содержимое РБС может быть передано на вход В БА. Кроме того, его биты с нечётными номерами могут анализироваться полем УСЛ1, а биты с чётными номерами — полем УСЛ0, что позволяет выполнять условные микропереходы в зависимости от состояния отдельных разрядов РБС (см. статью, посвящённую блоку микропрограммного управления).
Схема регистра РБС приведена на рисунке.
Регистр РБД отражает внутреннее состояние процессора. Его разряды имеют следующее назначение:
бит 0 является триггером центрального процессора ТЦП; он установлен, когда выполняется микропрограмма обслуживания селекторного или мультиплексного канала, и сброшен при выполнении микропрограммы процессора;
бит 1 — триггер первоначальной загрузки программы ТПЗП;
бит 2 — триггер состояния ожидания ТЖС (соответствует разряду PSW[14]);
бит 3 — триггер гашения системы ТГС;
бит 4 — триггер останова ТОСТ;
бит 5 — триггер ручной работы ТРУЧ;
бит 6 — триггер контроля машины ТКТРМ;
бит 7 — триггер первого сбоя ТПСБ.
Как обычно, весь РБД может быть загружен с выхода БА по тактовому импульсу ТИ4. Для ряда триггеров, кроме того, предусмотрено аппаратное управление.
Общая схема регистра РБД приведена на рисунке.
Сигнал аппаратного гашения (сброса) АГ1 сбрасывает все триггеры, составляющие РБД, кроме триггера первоначальной загрузки программы ТПЗП; последний при аппаратном сбросе очищается или устанавливается в зависимости от того, чем вызван этот сброс: нажатием кнопки «Загрузка» или любой другой причиной. Пока ТПЗП установлен, на пульте управления светится индикаторная лампа «Загрузка»; она гаснет при микропрограммном сбросе этого триггера, что указывает человеку на успешное завершение процесса загрузки (под этим понимается успешное окончание канальной программы, осуществляющей загрузку программы процессора с внешнего устройства, и последующую за этим загрузку PSW, с чего начинается её выполнение). Если операция загрузки завершилась с ошибкой, микропрограмма не сбрасывает ТПЗП, и индикатор продолжает гореть, давая знать человеку, что в процессе загрузки что-то пошло не так.
Триггер ТЖС устанавливается и сбрасывается микропрограммно в процессе загрузки нового значения PSW. Когда он установлен, на пульте управления горит соответствующий индикатор. С точки зрения программиста, в состоянии ожидания процессор не выполняет команды, но реагирует на разрешённые прерывания; операционная система переходит в это состояние, когда никакой работы нет. При обнаружении фатальной ошибки ОС тоже переводит процессор в ожидание, но с запрещёнными прерываниями, при этом загружая в PSW некорректный (нечётный) адрес команды — последний играет роль кода причины останова, давая возможность человеку понять, что случилось с системой (адрес команды и другие разряды PSW отражаются индикаторами на пульте управления).
В ЕС-1020 состояние ожидания реализовано микропрограммными средствами: при занесении единицы в ТЖС микропрограмма «крутится» в цикле, непрерывно проверяя наличие разрешённых прерываний или каких-либо внутренних событий, требующих её внимания; переход на выборку команды будет выполнен лишь после сброса ТЖС.
Триггер центрального процессора ТЦП сбрасывается только микропрограммно при завершении обслуживания канала, а вот устанавливается либо микропрограммно (например, при выполнении команды ЗАПУСК ВВОДА-ВЫВОДА, когда её «процессорная» часть закончена и начинается «канальная» — т. е. собственно запуск канальной программы), либо аппаратно — при начале микропрограммной приостановки для обслуживания какого-либо канала (МПРС) по соответствующему запросу. Схема аппаратной установки этого триггера показана на рисунке.
Как видим, ТЦП находится в правом верхнем углу — в самом конце довольно сложной схемы, включающей, помимо него, ещё два триггера и несколько логических элементов.
Первым в цепочке является ТКЦП — триггер конца цикла памяти. Он устанавливается по сигналу КША:=КША — это сигнал занесения адреса из любого источника в регистр адреса памяти РМН (т. е. сборка схемой ИЛИ сигналов вида РМН:=РМФЕ, РМН:=РГРИ и т. д.). Поскольку адрес заносится в РМН в первом такте доступа к памяти (в котором производится её считывание или стирание), ТКЦП устанавливается с началом обращения к памяти.
Сброс ТКЦП выполняется любым из трёх сигналов ХИ2, ЗПРГЦП и АПГ2. Первый из этих сигналов используется в той же ситуации, в какой он применяется для сброса триггеров, управляющих обращением к памяти и рассмотренных в предыдущей статье, — при возникновении фатального сбоя, делающего невозможным продолжение выполнения микропрограммы и немедленно вызывающим микропрограмму обработки этого сбоя; такт ХИ выполняется для вызова этого обработчика. Содержимое ячейки памяти, которая при этом считывалась, окажется разрушенным, поскольку регенерация не выполнена, но в такой ситуации это уже не играет особой роли.
Сигнал ЗПРГЦП выдаётся при записи или регенерации памяти, т. е. при завершении полного цикла обращения к ней более-менее штатным образом (без фатального сбоя, хотя, возможно, и с особым случаем адресации или защиты — при их возникновении цикл памяти выполняется до конца и лишь затем вызывается микропрограмма их обработки, как мы увидим в статье, посвящённой прерываниям).
Сигнал АПГ2 нигде в [1] не упоминается; вероятно, это один из сигналов аппаратного гашения (сброса).
Таким образом, ТКЦП установлен на протяжении всего цикла обращения к оперативной памяти любого вида (ОП, ЛП, МП) или памяти ключей защиты. Его инверсный выход, как видим из схемы, поступает на один из входов схемы И; двумя другими её входными сигналами являются МПРСК и ТПСБ, причём второй из них тоже инверсный. Соответственно, на выходе этой схеме появляется логическая единица, когда ТПСБ и ТКЦП равны нулю, а МПРСК — единице. Эта схема разрешает прохождение запроса на микропрограммную приостановку для обслуживания каналов, подаваемого в виде сигнала МПРСК. Этот запрос не может быть обслужен, если в данный момент выполняется обращение к памяти, ведь сначала надо выполнить в неё запись или регенерацию — именно для этого потребовался триггер ТКЦП. Что же касается второго триггера, ТПСБ, — это триггер первого сбоя, устанавливаемый, когда схемы контроля процессора обнаружат какой-то сбой. Понятно, что при нормальной работе он сброшен; его установка блокирует обработку запросов каналов, поскольку сначала надо разобраться с возникшей неисправностью.
Выход схемы И, пропущенный через инвертор (инверсный сигнал ОСТ МПРС В УПО), нас не интересует; его назначение неизвестно.
А вот другой путь сигнала МПРС, прошедшего схему И, для нас важен. Как видно по схеме, он приводит к установке безымянного триггера по синхроимпульсу ХИ1 — т. е. в начале холостого такта, используемого для прерывания выполнения текущей микропрограммы и вызова микропрограммы обслуживания канала. Сбрасывается этот триггер сигналом ТИ1 — т. е. в начале первой микрокоманды обслуживания канала. Данный триггер является вспомогательным, единственное его назначение — сохранить на протяжении холостого такта запрос на МПРС, чтобы установить по ХИ4, т. е. в конце вызова микропрограммы обслуживания канала, целевой триггер ТЦП, переключив, тем самым, процессор в режим работы с каналами. Установку ТЦП блокирует сигнал контроля машины КТРМ — он формируется при обнаружении какой-либо машинной ошибки; в этом случае вместо вызова микропрограммы обслуживания канала будет вызван обработчик машинных ошибок.
Триггер гашения системы ТГС управляется микропрограммно. Он установлен во время работы микропрограммы гашения, т. е. сброса, и влияет на работу схем контроля (во время сброса контроль, вообще говоря, блокируется, так как в этот момент регистры процессора находятся в неопределённом состоянии и могут содержать неверные контрольные разряды).
Триггер останова ТОСТ вызывает переход процессора в остановленное состояние перед выборкой очередной команды, при этом на пульте загорается соответствующая лампа.
В отличие от состояния ожидания, отражаемого триггером ТЖС, состояние останова, с точки зрения программиста, является чисто аппаратным. Программа не может перевести процессор в останов, переход в это состояние всегда является следствием внешних событий:
первоначально процессор переходит в останов сразу после завершения сброса (в ЕС-1020 — по окончании микропрограммы сброса, которая его и установит), если только сброс не связан с нажатием на кнопку «Загрузка», чем инициируется первоначальная загрузка программы (в последнем случае процессор переходит в состояние загрузки и либо «зависает» в нём, если произошла какая-то ошибка, или по окончании загрузки переходит к обычному выполнению программы);
процессор может быть в любой момент остановлен человеком нажатием соответствующей кнопки на пульте управления; в этом случае текущая команда будет выполнена до конца, обслужены все разрешённые запросы прерываний, и процессор остановится (начатые ранее операции ввода-вывода продолжатся: логически каналы являются отдельными устройствами, работающими без участия процессора);
процессор останавливается также в «отладочных» ситуациях; например, на пульте управления может быть задан останов при попытке выполнить команду по определённому адресу;
в многопроцессорных или многомашинных системах процессор может быть остановлен поступлением сигнала от другого процессора (машины).
Пуск процессора, т. е. переход из состояния «стоп» в состояние «работа», когда он может выполнять команды и обслуживать прерывания, выполняется нажатием кнопки «Пуск» или поступлением соответствующего сигнала от другого процессора (машины).
С точки зрения электроники, состояние «стоп» может быть реализовано различными способами. В ЕС-1020 оно реализовано микропрограммно: микропрограмма выборки команды проверяет состояние триггера ТВВВ (о нём будет сказано в статье про прерывания), на которое влияет, в том числе, состояние ТОСТ, и ведёт себя соответствующим образом (как правило, «крутится» в цикле, пока изменившееся состояние не позволит ей заняться чем-то более полезным).
Состояние ТОСТ может меняться микропрограммно или аппаратно; схема его аппаратной установки и сброса приведена ниже. Разбирать её мы не будем; заметим лишь, что и установка, и сброс аппаратными средствами тесно связаны с пультом управления, который будет рассматриваться отдельно. В частности, ТОСТ сбрасывается при нажатии четырёх кнопок «Чтение», «Запись», «Занесение АК» и «Пуск»; лишь последняя из них запускает программу, другие три заставляют выполнить процессор определённые ручные операции, после чего возвратиться в состояние останова.
Триггер ручной работы ТРУЧ логически связан с предыдущим. Как видно на приведённой ниже схеме, он устанавливается при определённых пультовых событиях; микропрограмма анализирует его состояние и определяет, что она должна сделать (большинство функций пульта управления реализовано, на самом деле, микропрограммными, а не аппаратными средствами). Его сброс производится микропрограммно.
Два последних разряда РБД, триггер контроля машины ТКТРМ и триггер первого сбоя ТПСБ, связаны с обработкой машинных ошибок и будут рассмотрены в соответствующей статье.
Литература
В. В. Пржиялковский и др. Процессор ЭВМ ЕС-1020. Под общей редакцией А. М. Ларионова. — М., "Статистика", 1975.
Комментарии (20)
Kgstranget
27.05.2023 12:07Вы уж поправьте 2020 или 1020, кстати я обслуживал дисковую подсистему.
SIISII Автор
27.05.2023 12:07+1ЕС-2020 -- это процессор ЭВМ ЕС-1020, включая память и стойку питания. А процессор без памяти и питания -- ЕС-2420. Отсюда и двусмысленное восприятие фраз, где упоминается тот или иной шифр.
ADD. Поправил заголовок и этой статьи, и прошлой -- с чего-то пропустил ЭВМ. Спасибо, что пнули.
Tzimie
27.05.2023 12:07А вот интересно, насколько по сложности разные машины серии ЕС больше или меньше классической СМ-4?
SIISII Автор
27.05.2023 12:07+2ЕСки очень, Очень, ОЧЕНЬ сильно сложнее, чем СМки. Недаром процессор СМки -- один ящик в стойке, а ЕСки -- вся стойка, а у некоторых каналы -- ещё одна стойка.
Tzimie
27.05.2023 12:07А насколько оправдана эта сложность была? Мне тогда казалось что СМ PDP красива, особенно система команд, а ЕС IBM урод и там много костылей.
А если сравнить с младшими вариантами VAX, где и памяти сравнимо, и виртуальная память, и 32 бит, кластера итд?
SIISII Автор
27.05.2023 12:07+3Ну, система команд PDP-11, как по мне, -- лучшая среди 16-разрядных, а VAX-11 -- среди 32-разрядных, но, как говорится, есть нюансы.
Адресация у DECовских машин более гибкая и эффективная, что, естественно, способствует сокращению объёма программы и потенциально -- повышению производительности. В то же время базовая система команд Системы 360 более проста для реализации (пять чётких форматов команд, не имеющих значимых с точки зрения выборки-декодирования исключений, более простая адресация -- обычная сумма одного-двух регистров и смещения, без всяких модификаций регистров, косвенной адресации и т.п.), и её намного проще "положить на конвейер" -- уже первые старшие модели Системы 360, как и наша ЕС-1050, были конвейерными, и, понятно, по производительности рвали любую PDP-11 как тузик грелку. Сделать конвейерную PDPшку или VAX... можно, но значительно сложней (а соответственно, куда больше логики нужно -- и на тогдашнем технологическом уровне это было недостижимо из соображений стоимости и габаритов).
Кроме того, система команд у Системы 360 побогаче будет, а в дальнейшем она всё расширялась и продолжает расширяться -- при этом умудряются не сломать совместимость и поддерживать простоту кодирования (сейчас, например, какое-нибудь там шифрование выполняется одной командой -- и, естественно, обеспечивается намного более высокая производительность, чем у самого навороченного "обычного" процессора, где это надо делать программно). Наличие команд десятичной арифметики, например, резко упрощает жизнь разработчикам экономических приложений -- не надо никаких мер предосторожности, чтоб результаты получались такие же, как при ручных вычислениях (в двоичной возможны нюансы из-за округления; плюс диапазон представимых чисел -- госдолг США, как мы помним, стало возможным хранить лишь в 64-разрядном регистре, ну а в Системе 360 -- запросто, там двоично-десятичные числа лежат в памяти и могут иметь до 31 цифры плюс знак; в PDP-11, кстати, теоретически присутствовал "коммерческий набор команд" -- CIS, но, похоже, встречался крайне редко). Команда TRT (одна из "костыльных" в том плане, что один из операндов является неявным и лежит в строго определённом регистре -- полей для кодирования не хватало) резко упрощает написание программ разбора текста (на ней, грубо говоря, половина лексического анализатора любого ассемблера/компилятора держится). Есть пересылка сразу порции данных (до 256 байтов), а также логические операции над байтовыми полями переменной длины -- соответственно, обнулить память можно куда быстрей, чем чисто программно в цикле (во всяком случае, теоретически: зависит от особенностей реализации; скажем, продвинутая модель, увидев "исключающее или" с одним и тем же стартовым адресом, может просто обнулить эту память, причём, естественно, не побайтово, как предполагается концептуально, а на всю ширину физического доступа в конкретной модели).
Ещё один аспект -- ввод-вывод. У Системы 360 он логически отделён от процессора и свален на каналы, что потенциально, не выходя за рамки архитектуры. позволяет реализовать очень быстрый обмен. У PDPшки всё висит на единственной довольно медленной шине; интенсивный обмен с диском запросто затормозит работу процессора и т.д. (Понятно, что у младших, а отчасти и средних моделей Системы 360 та же проблема -- но она вытекает не из архитектуры, а из реализации; в старших моделях процессор и каналы работают подлинно параллельно и тормоза возникают лишь при одновременном обращении к одному и тому же, выражаясь более современными терминами, банку памяти, -- но там выручает кэш, который у старших моделей появился довольно быстро, хотя у самых первых ещё не было, вроде бы). Поэтому для управляющих применений (где надо постоянно опрашивать битики в регистрах устройств и т.п.) PDPшка или, скажем, современный ARM подходит куда лучше, но вот при обработке больших массивов информации -- наоборот. (Попутно замечу, что великолепнейшая виртуализация машины, реализованная ещё в начале 1970-х в VM/370, так и осталась непревзойдённой по сей день -- если не считать z/VM, конечно, но она -- наследница VM/370 и работает на z/Architecture, выросшей из Системы 360 и сохранившей с ней совместимость на прикладном уровне; во многом она достигнута именно благодаря унифицированному вводу-выводу: гипервизору ничего не нужно знать про работу внешних устройств, если с ними умеет работать гостевая ОС -- он просто преобразует канальные программы в плане физических адресов памяти да передаёт их каналам на выполнение; в той же PDPшке виртуализация... как минимум, проблематична, в IA-32 aka x86 и вовсе невозможна без специальный аппаратной поддержки из-за абсолютнейшей кривизны архитектуры -- Интел, кажется, смогла воплотить все мыслимые и немыслимые архитектурные ошибки...)
Добавьте к этому аппаратный контроль. У PDPшек контролировали разве что чётность оперативной памяти и памяти микропрограмм; у Системы 360 контроль намного более полный, причём во многих более поздних моделях имеются средства восстановления, зачастую позволяющие продолжить работу при случайных сбоях, а уж обнаруживать проблемы вообще в 100% случаев (в младших моделях, особенно ранних, -- в частности, в ЕС-1020, -- он не такой полный, поэтому некоторые сбои будут оставаться "незамеченными", но большинство вещей всё ж контролируется; в частности, АЛУ выполнено в двух экземплярах, и результаты его работы сравниваются -- вот и куда больший объём аппаратуры по сравнению с СМками, ведь тогдашнее АЛУ -- это половина процессора).
Система 360 изначально предполагала возможность построения многопроцессорных систем. Правда, в этой версии архитектуры это было проработано довольно плохо, но опыта-то не было. Когда набрались, многое переделали -- уже в Системе 370, и это сохраняется до сих пор (с некоторыми расширениями).
Насчёт костылей в системе команд Системы 360 не согласен :) Они там есть, конечно, но их, пожалуй, меньше, чем в PDP-11, и существенно меньше, чем у VAX, хотя система команд по функционалу богаче PDPшки. Например, команда XOR в PDPшке -- костыльная по сравнению с остальными, у неё один из операндов обязательно должен лежать в регистре; имеется совершенно дурацкая команда... ээээ... MARK, кажется (вроде б компилятором Фортрана используется, но уж не помню столь интимные подробности); нет логических сдвигов (только арифметические), ещё там что-то было... MMU на многих моделях не позволяет реализовать полноценную виртуальную память (с загрузкой/выгрузкой задач по частям -- поскольку не обеспечивает правильный "откат" при прерывании в процессе выполнения команды), а там, где позволяет (PDP-11/70, например), это делается программными плясками (ОС должна сама выполнить "откат", MMU просто сохраняет нужную для этого информацию в одном из своих регистров) -- ну а в мэйнфреймах, когда виртуальную память сделали (в Системе 370, причём не сразу -- но очень быстро), сразу сделали правильно (принципиально она ничем не отличается от современных архитектур -- те же самые таблицы переадресации в памяти).
ermouth
27.05.2023 12:07У вас, конечно, ну очень пристрастный взгляд. Ничуть не против, но всё же )
MARK не сильно большее извращение, чем тот-же TRT. Оба – трюки, придуманные под конкретный запрос.
Первый – потому что оказалось, что кроме подпрограмм (под которые обычный RET и сконструирован) есть ещё и функции, а им надо передавать аргументы, и лучше на стеке, и при возврате надо как-то указатель стека правильно передвигать. Дичь, конечно, но очень занятное решение.
Второй – я вообще не знаю, как TRT появился. Есть подозрение, что делали под криптографию, но очень может быть, что оно оттуда же, откуда вся эта сложная кухня с адресацией: Бэкус насоветовал, чтобы Фортран удобнее компилировать было.
И вообще, если уж ассемблеры сравнивать в смысле instruction set architecture – то WASM точно самый красивый )
SIISII Автор
27.05.2023 12:07Ну почему пристрастный. Я на PDPшках (СМках, точней, -- но не суть) прилично программировал на асме, и, как уже сказал, считаю его лучшим из 16-разрядных. Просто там тоже свои извраты есть, как и везде.
А причём здесь WASM, кстати? Это ж не архитектура проца, чтоб иметь свою систему команд.
ermouth
27.05.2023 12:07А причём здесь WASM, кстати? Это ж не архитектура проца
Ну так у /360 архитектур процев и окружений тоже много всяких, а ассемблер более-менее един. Wasm в каком-то смысле тоже единый ассемблер для очень разных архитектур и окружений, причём такой, в котором куча детских болезней вполне уже взрослых архитектур генетически невозможна.
В реальный машинный код оно преобразуется однопроходным транслятором, так что считайте что у вас в процессоре просто второй декодер опкодов и второй слой микрокода, который реализует стековую машину.
SIISII Автор
27.05.2023 12:07+3Что же касается сравнения с VAXом, то с ним корректней уже будет сравнивать поздние варианты Системы 370, а не ранние Системы 360 -- ведь между ними 10, если не больше, лет разницы. "Общая" система команд у VAX приятней будет, в общем и целом; в отдельных вещах он лучше и в специальных случаях, а Система 370 -- в других (десятичную арифметику, кажется, никто лучше так и не сделал -- одна из причин доминирования мэйнфреймов в финансовом секторе). По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).
На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено. У VAX ничего подобного я не видел -- хотя с поздними вариантами не знаком. В IA-32 было "жалкое подобие левой руки" -- таблицы дескрипторов со шлюзами вызова позволяют, теоретически, добиться того же, но всё было спроектировано настолько криво, что этими возможностями никто не пользовался (и AMD выпилила их, делая 64-разрядный вариант архитектуры, -- что впоследствии скопировала Интел, провалившись со своей IA-64 aka Itanium). В общем, в плане системной архитектуры, на мой взгляд, Система 360 и её наследники -- лучшее, что было и есть. По системе команд -- VAX лучше, если не брать частности (которые в него вполне можно было бы добавить, конечно). По простоте реализации -- безусловное превосходство Системы 360 (ну, это неудивительно: в первой половине 1960-х развернуться было особо негде, железо ограничивало -- отсюда, кстати, ряд костылей и неудачных решений, и в первую очередь -- 24-разрядный адрес памяти; просто, похоже, никто не думал, что через 20 лет этого будет мало). По гибкости ввода-вывода -- превосходство VAX, но по пропускной способности -- Системы 360.
В общем, разные архитектуры друг друга не исключают, а дополняют. Ставить Систему 360 в качестве управляющей машины -- верх идиотизма, пытаться заменить один мэйнфрейм тыщей персоналок -- примерно то же самое. Надо исходить из задачи и выбирать адекватные средства.
Tzimie
27.05.2023 12:07Спасибо за подробный ответ
На VAX помнится, системные библиотеки отображались в верхние 2 гига read-only, так что большинство вызовов не требовали смены адресного пространства
А зачем 1000 дисков? Поставить их вы бы смогли и каналы. А по конфликтам с памятью? Вот если бы в программе канала можно было бы написать raid... Но вроде в канале были очень примитивные программы
SIISII Автор
27.05.2023 12:07А зачем сейчас столько дисков ставят? Хранение и обработка гигантских объёмов информации, естественно.
Канальные программы -- да, примитивные, но свою задачу (разгрузку ЦП от управления вводом-выводом) вполне себе выполняют.
Про конфликты с памятью вроде сказал уже. Если память разделена на несколько банков, то, пока обращения идут к разным банкам, их легко распараллелить средствами многопортового контроллера памяти; кстати говоря, на СМках с 4 Мбайтами память была двухпортовой: один порт для проца, второй -- для периферии. Просто в Системе 360 проще распараллеливать, поскольку память там является единственной общей точкой -- ну а в более привычных архитектурах процессор напрямую обращается к устройствам и ими управляет, что требует обеспечить соответствующую связь, т.е. делать или общую шину, или огромное количество соединений точка-точка с коммутаторами, -- первое медленно, когда устройств много (некритично для мини-ЭВМ, но недопустимо для мощного мэйнфрейма), второе -- очень сложно и затратно по железу.
vadimr
27.05.2023 12:07На VAX помнится, системные библиотеки отображались в верхние 2 гига read-only, так что большинство вызовов не требовали смены адресного пространства
В VM/370 так тоже было сделано, не обязательно 2 гига – на сегментной основе, и настраивалось на уровне отдельных приложений. Это называлось “разделяемые сегменты”. В частности, XEDIT в CMS, помнится, был один в разных адресных пространствах.
SIISII Автор
27.05.2023 12:07Если память не изменяет, в VAX разделение памяти на 2 нижних гига и 2 верхних навязывалось архитектурой, -- но, возможно, с чем-то путаю, а искать сейчас лениво :) Ну а в Системе 370 и последующих у всей памяти полное равноправие. Вообще, в смысле системной архитектуры IBMовские мэйнфреймы -- пожалуй, самые прямые из всех машин (а одни из самых кривых, если не самые кривые, -- ПК :) ).
rutenis
27.05.2023 12:07Уродливость системы команд -- понятие, которое зависит от вкуса, привычек, опыта работы с ними. Если сравнивать, к примеру, с MIPS или ARM (ранними), так ЕС вполне достойно смотрится.
Только зачем нужны красивые системы команд, когда на ассемблере не пишут практически ничего? Даже операционные системы. Уже при написании IBM MVS широко использовался язык PL/S, а это середина 1970-х.
SIISII Автор
27.05.2023 12:07От красоты или уродства системы команд, как минимум, зависят сложность её декодирования (IA-32 -- кошмар, Система 360 -- прекрасно, ARM -- где-то посредине) и сложность создания эффективного кодогенератора для компиляторов.
rutenis
27.05.2023 12:07Одни из самых сложных процедур в оптимизирующем кодогенераторе -- это поиск в программе паттернов, которые бы отображались напрямую на комбинации команд и режимов адресации в прикладном режиме. И я не сказал бы, что красивая система команд однозначно упрощает этот процесс. Приведу пример из PDP-11.
Имеется автодекрементная адресация, которая по архитектуре применима ко многим командам. Однако, чтобы задействовать этот режим адресации для генерации команд помимо MOV, требуется научить кодогенератор отыскивать очень специфичные (и редко встречающиеся) комбинации в исходном коде. Теперь, гипотетически, создадим другую, не такую красивую систему команд, в которой автодекрементую адресацию оставим только как особый случай команды MOV. Кодогенерация при этом, очевидно, упрощается: нет лишних комбинаций команд -- не нужно выявлять для них паттерны -- нет лишних проблем.
(Нетрудно заметить, что выше я просто-напросто пересказал кусок из идеологии RISC. Ну да, набор команд у них не назовешь однозначно красивым.)
SIISII Автор
27.05.2023 12:07Ну, что эффективная, но сложная система команд однозначно затрудняет создание хорошего кодогенератора -- это, конечно, так. Но, как по мне, это не повод делать неэффективную систему команд -- а любые классические RISCи именно такими и являются. Недаром постепенно они сами от своих идей и отошли. Скажем, у современных ARMов единственное, что от идеологии RISC осталось, -- это отсутствие команд, прямо обрабатывающих данные в памяти, все остальные атрибуты они утратили: есть сложные команды, выполняемые несколько тактов, команды имеют разную длину (система команд Thumb), декодирование стало весьма нетривиальным...
Ну и про ручное программирование всё ж не стоит забывать. Да, на ассемблере пишут редко, но иногда такая нужда бывает. Кроме того, помня, что 90% времени расходует 10% кода, в некоторых задачах вполне оправданной может быть ручная ассемблерная оптимизация. Естественно, подходить надо без фанатизма, но и без пофигизма (зачем оптимизировать? поставим более мощный проц! а что мобила из-за этого работает от батареи 2 часа, а не 20 -- пофиг, у конкурентов то же самое).
rutenis
Я встречал упоминание о ещё двух вариантах:
Срабатывание схем аппаратного контроля может сразу перевести ЦП в останов, а не вызывать соответствующее прерывание.
Некорректное PSW программных прерываний на некоторых моделях также может перевести ЦП в останов.
SIISII Автор
Останов при срабатывании схем контроля -- это так называемый тяжёлый останов. Отличается от обычного, в частности, тем, что при нём нельзя процессор просто взять и запустить -- он будет стоять, пока не будут сброшены признаки ошибок. Архитектурой сие никак не регламентируется, так как является полностью зависящим от реализации. Ну а обычный останов -- это именно что архитектурное состояние, общее для любых моделей.
Это уже зависящее от реализации поведение. В общем случае процессор уходит в бесконечную цепочку прерываний, выйти из которой можно только сбросом (что тоже регламентируется архитектурой).