Аппаратная поддержка языка пользователя — основная концепция мультипроцессорных систем

Проблема повышения уровня языка пользователя

Существуют три уровня алгоритмических языков: ассемблеры, автокоды, языки высокого уровня (ЯВУ).

Ассемблеры — машинно-ориентированные языки, низкого уровня, допускающие трансляцию "один в один".

Автокоды — также машинно-ориентированные языки допускающие конструкции, не транслируемые "один в один". (Некоторая классификация языков исключает автокоды, предполагая, что ассемблер может обладать макросредствами (такой ассемблер - макроассемблер), обеспечивающими его лаконичность.)

ЯВУ — не машинно-ориентированные (проблемно-ориентированные) языки, обладающие лаконичностью, большим набором выразительных средств, обеспечивающие свободную рекурсивную структуру, с вложенными условными выражениями, с процедурной нотацией и инфиксными арифметическими выражениями. ЯВУ — язык пользователя-алгоритмиста, которому нет необходимости опускаться на уровень машинного представления, в том числе до уровня машинных команд.

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

Введение в машинный язык сложных операций, соответствующих конструкциям ЯВУ, служит повышению производительности.

Есть другой аспект повышения уровня входного языка (самого низкого уровня языка пользователя): создание семейств программно-совместимых ВС. Совместимость на уровне ассемблеров (реализована в ЕС ЭВМ) значительно сдерживает развитие новых поколений, оставляя их в рамках неизменных архитектурных решений. Требование совместимости на уровне ассемблера-ЯВУ предоставляет широкие возможности поиска, выбора, развития поколений, что видно на примере развития проектов МВК "Эльбрус". Каждая система может иметь свой внутренний машинный язык, обусловленный своими архитектурными особенностями, т.е. своей для каждой модели аппаратной поддержкой языковых конструкций. Он не доступен пользователю и проявляется только в объектном коде — коде оттранслированной программы, к которой пользователь отношения не имеет.

Насколько могут быть архитектурно отличны модели, говорит хотя бы то, что в основе ЦП "Эльбрус-2" лежит безадресная система команд с динамическим распределением работ между ИУ, а в основе ЦП "Эльбрус-3" — "длинное" командное слово со статическим планированием использования ИУ.

В проектах МВК "Эльбрус" исключено ассемблерное программирование. Исключение уровня ассемблера значительно упростило создание системного программного обеспечения, разработку сложных систем реального времени и др. Оно позволило в несколько раз поднять производительность труда программистов в наиболее сложных областях применения.

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

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

Такая идеология обсуждается в связи с развитием семейства "Эльбрус". Однако здесь нет полной ясности из-за того, что для эффективности системы трансляции непосредственно в систему команд микропроцессора требуется действительно развитая система его команд.

Дело в том, что любая трансляция использует два принципа — компиляции и интерпретации. Существует оптимальное соотношение этих принципов при реализации трансляции. Компиляция на язык слишком низкого уровня (с которого затем производится интерпретация аппаратно), кроме собственной сложности и трудоемкости, приводит к значительному увеличению объектного кода. Надо учитывать, что по сравнению с "ручным" программированием транслятор и без того дает программы, по объему и по времени выполнения значительно (раза в два) менее эффективные. Такая неэффективность усугубляется низким уровнем языка, на который производится трансляция. Значит, необходим промежуточный "оптимальный" язык, на который целесообразна компиляция, а с него затем — интерпретация. Таким языком и может быть машинно-ориентированный ассемблерный язык ВС. Это соответствует как общей идее RISC -архитектуры, достаточно себя зарекомендовавшей, так и тому очевидному факту, что комплексирование большого количества микропроцессоров в ВС дает новое качество, выражающееся в развитой системе команд ВС. В такой системе команд в частности должны отражаться способы организации и синхронизации параллельных процессов. Не все команды реализуются только комплектующими микропроцессорами, а требуют использования и других средств ВС. Таким образом, на практике целесообразность полного отсутствия ассемблерного программирования может не подтвердиться.

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

Поддержка типов — теговая архитектура

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

ЯВУ по способу работы с типами данных делятся на два класса: с динамическими и статическими типами, или на динамические (не типизованные) и статические (типизованные) языки. В статических языках тип данных задается однажды на все время их существования. (В Паскале — в описании, для динамических переменных — в описании ссылок). В динамических языках указание типа сопровождает каждое вхождение данных в текст программы и, вообще говоря, может меняться на протяжении жизни этих данных. Например, одной величине можно в одном месте программы присвоить тип целое, а в другом — битовый набор. (Скажем, при моделировании ВС мы можем с помощью операций целочисленной арифметики вычислить адрес, затем надо произвести структурное исследование этого адреса, к примеру — выделить группу разрядов этого адреса и т.д.)

Как говорилось выше, в МВК семейства "Эльбрус" как основной язык пользователя реализован динамический язык. Для пользователя он — ЯВУ, для машины — ассемблер. Каждая величина сопровождается указанием типа, для чего в каждом машинном слове предусмотрены дополнительные разряды, в которые пишется тег — код соответствующего типа.

Аппаратно реализованные типы в "Эльбрусе-2": целое 32-разрядное, целое 64-разрядное, вещественное 32-разрядное, вещественное 64-разрядное, вещественное 128-разрядное, битовый набор 64-разрядный, дескриптор массива, косвенное слово, метка процедуры, метка перехода, семафор.

Введение тегов, не исключающее применение статических ЯВУ, определило понятие теговой архитектуры.

Теги обеспечивают:

1. аппаратное управление алгоритмами обработки данных. Данные на входе ИУ распознаются по типам, и ИУ настраивается на вид обработки: например, сложение целых, сложение вещественных и т.д.;
2. упрощение трансляции, т.к. сокращается количество кодов операций;
3. семантический контроль вычислений: возможна сигнализация (прерывание) в том случае, когда выполняется операция, не соответствующая типу данных (например, операция, которая не должна производиться над адресной информацией);

4. контекстную защиту данных: а) каждая процедура выполняется над отведенной ей областью памяти, в) известны области памяти тех процедур, внутри которых она запущена, и с) все это образует адресный контекст выполняющейся процедуры. Он определяется совокупностью доступных ей дескрипторов массивов (сегментов), описывающих области доступной памяти. Дескрипторы, как адресная информация, обладают тегами. Аппаратура осуществляет контроль над тем, чтобы над адресной информацией не выполнялись действия, приводящие к расширению адресного пространства, т.е. к нарушению защиты памяти. Контекст может меняться только при процедурных переходах и полностью определяется меткой процедуры. Метка — тоже адресная информация, и действия над ней также контролируются аппаратурой. Изменить метку нельзя; по ней можно только вызвать новую процедуру.

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

   Пункты 3 и 4 определяют типовый контроль, осуществляемый с помощью тегов;
5. реализацию формирования параметров процедур "по ссылке" и "процедурой". Адреса для команд записи и считывания задаются операндами адресного типа. Формирование параметров процедур "по ссылке" производится в следующем случае: если результат считывания — адресная информация, то операция считывания автоматически повторяется по новому адресу, и так до тех пор, пока не будет считано значение другого типа. Второй случай — формирование параметров процедур "процедурой": если результат считывания — имя процедуры, то она автоматически запускается, и результат ее выполнения рассматривается как считанное значение.