Создание современной высокопроизводительной мультипроцессорной системы в рамках проекта МАРС выдвигает ряд новых требований ко всем имеющимся компонентам и способам их взаимодействия.
В настоящей работе описывается разработанная авторами архитектура базового процессорного модуля Кронос-П2.5 и общие принципы взаимодействия модулей в макете МАРС.
Для существенного повышения уровня интеллектуализации разрабатываемых систем необходимо создание большого объема высококачественного программного обеспечения. Очевидно, что осуществить поставленную задачу, обеспечить высокий уровень надежности, модульность и развиваемость систем обработки данных можно, используя только новейшие достижения программирования и базируясь на достаточно развитом языке высокого уровня.
С момента появления в 1982 г. описания языка Модула-2, по многим параметрам превосходящего традиционные языки программирования и успешно конкурирующего с языком Ада, группой авторов была начата работа по созданию ряда процессоров с системой команд, ориентированных на языки высокого уровня (ЯВУ). Сама идея системы команд, ориентированных на ЯВУ, не нова и берет свои истоки в архитектурах таких машин, как KDF-9, Burroughs, Эльбрус. Создатель языков Паскаль, Модула и Модула-2 Н. Вирт с группой коллег провел разработку персональной ЭВМ, ориентированной на язык Модула-2 в Цюрихской Высшей технической школе, вследствие чего была создана машина Lilith со специальной системой команд, именуемой M-кодом.
Мы использовали позитивный опыт этой разработки при проектировании процессоров семейства Кронос. В то же время было очевидно, что архитектура базового процессора системы МАРС должна быть ориентирована, в первую очередь, на долгосрочные перспективные направления компьютерной науки. Эти соображения привели к созданию модифицированного варианта М-кода (в дальнейшем называемого просто M-кодом) и процессоров для его аппаратной интерпретации.
Характерными чертами M-кода и архитектуры процессоров Кронос являются:
В макете системы МАРС в качестве универсальных центральных будут применены процессоры Кронос-П2.5, оснащенные базовой операционной системой Excelsior.
Процессор Кронос-П2.5 состоит из двух модулей, связанных между собой локальной шиной: собственно процессора - аппаратного интерпретатора M-кода и модуля связи с системной шиной. Предполагается разработать несколько различных модулей связи для встраивания процессора в системы с различными шинами. При этом каждый из них кроме схем управления шиной должен содержать диспетчер памяти и оперативную память объемом около 0,5 Мбайт со временем доступа 200 нс. Наличие такой локальной памяти с малым временем доступа позволяет достигать достаточно высокой производительности процессора независимо от пропускной способности системной шины и количества активных устройств на ней.
Собственно процессор является устройством с микропрограммным управлением, построенным на микропроцессорных секциях серии 1802. В процессоре применены однофазная схема синхронизации и двухступенчатая конвейеризация, позволяющая совместить во времени исполнение текущей микрокоманды и выборку следующей из ПЗУ микропрограмм. Предполагаемый период тактовой частоты - 200 нс.
Процессор содержит следующие функциональные блоки (см. рисунок):
Многие команды M-кода такие, как загрузка на стек короткой константы или операции целочисленного сложения и вычитания, исполняются процессором за один такт. Учитывая время выборки команды (0,75 такта) при тактовой частоте 5 МГц, полное время исполнения простых команд составляет 350 нс, что соответствует производительности 2,86 млн. операций в секунду.
Чтобы определить место процессора Кронос в макете системы МАРС, необходимо подробнее рассмотреть дисциплину межмодульного взаимодействия в макете.
Основным принципом взаимодействия модулей в макете являются синхронизация и обмен данными через так называемые каналы. Логически такой канал представляет собой очередь (вместе с механизмом синхронизации). Обращение любого процесса к такой очереди происходит успешно, если она готова принять или передать данные. В противном случае обратившийся процесс задерживается до наступления готовности очереди. Физически каждый модуль системы содержит только принимающие и передающие "половинки" очередей, которые логически стыкуются с "половинками" очередей других модулей, задавая желаемую конфигурацию системы.
Канал, работающий на передачу, считается готовым, если в нем есть место для записи данных, работающий на прием - если в нем есть данные. В канале имеется признак ожидания, говорящий о том, что его готовности ожидает какой-либо процесс. Если канал готов и у него установлен признак ожидания, то этот признак сбрасывается, а номер этого канала помещается в очередь готовых каналов. Следует отметить, что в эту очередь попадают номера тех каналов, на которых были задержаны процессы.
Если канал готов, то процессор, исполнивший команду обращения к каналу, осуществляет пересылку данных между арифметическим стеком и буферной памятью канала. Если канал не готов, то указатель на дескриптор текущего процесса помещается в таблицу задержанных процессов по адресу, соответствующему номеру канала. Этот факт регистрируется в канале и процессе установкой признаков ожидания. Далее процессор проверяет наличие данных в очереди готовых каналов. Если она не пуста, то процессор извлекает из нее первый элемент и начинает исполнение процесса, задержанного на канале с таким номером.
Если очередь готовых каналов пуста, то возбуждается прерывание. При этом ОС разрешает прерывания по появлению данных в очереди готовых каналов и определяет процесс (из числа готовых), на который передает управление.
Для более эффективного взаимодействия процессов в различных системах обработки данных предлагается:
Процессор Кронос в системе, построенной по описанным принципам, представлен внешнему миру набором каналов, одна часть которых используется аппаратно, а другая - программно. При этом программная работа с каналами организована без дополнительных обращений к ОС, с помощью непосредственного использования команд доступа к каналу.
Распределение процессов по процессорам, определение соответствия между физическими и логическими каналами производится обращением к процедурам специальных модулей ОС и может быть выполнено как автоматически, так и непосредственно в самой программе с применением любой необходимой пользователю стратегии.
Важным свойством введения понятия канал является обеспечение логической независимости процессов друг от друга. Вместо сложной и малоэффективной синхронизации типа "процесс - процесс" транспьютерная техника позволяет ограничиться рассмотрением взаимодействия "данные - процесс".
Аппаратное управление процессами при работе с каналами снижает накладные расходы по времени на межпроцессное взаимодействие до уровня, позволяющего разбивать любую задачу на множество небольших, тесно взаимодействующих процессов. Реализация указанных механизмов и принципов открывает перспективы качественного повышения суммарной производительности системы за счет увеличения числа процессоров.