Машинный интерфейс, независимый от технологии
Характеристики машинного интерфейса
Сравнивая MI с обычным машинным интерфейсом, мы отмечаем, что MI — интерфейс высокого уровня. Дело в том, что многие команды MI выполняют очень сложные функции. Например, не многие обычные машинные интерфейсы содержат функции вызова, поддерживающие как раннюю, так и позднюю компоновку, для них более характерны обычные команды перехода.
Чтобы лучше понять разницу, разберем команду обычного машинного интерфейса (см. рисунок 4.5). Она состоит из кода операции и одного или нескольких полей операндов. Команды могут быть арифметическими (в каждом компьютере есть команда сложения), передачи управления и манипуляции с данными. Самое важное, с какого рода операндами имеют дело эти команды.
Обычные машинные интерфейсы работают с содержимым регистров, памяти или непосредственно с данными, записанными в самой команде. Иначе говоря, они "не подозревают" о данных приложения или операционной системы. Возьмем стандартную команду "регистровое сложение". Она задает два регистра процессора и выполняет операцию, извлекая биты из одного регистра, складывая их с битами из другого регистра и помещая результат в определенное место. Смысла этих битов команда "не понимает" —о нем "заботится" программа. Для машины это просто набор битов, к которому применяется алгоритм сложения. То, что в регистрах находятся, например, имена двух сотрудников и поэтому рассматривать их в качестве арифметических операндов нет смысла, никого не волнует. Операции этого уровня просто механически обрабатывают содержимое регистров или памяти.
Мы уже говорили о недостатке такой структуры — ее существенной зависимости от аппаратной технологии. Так как команды работают в адресном пространстве, с областями ввода/вывода и регистрами, они привязаны к этим физическим структурам. Изменение последних может потребовать изменения команд. Значит, преобразование существующих программ может вызвать существенные проблемы.
Машинный интерфейс AS/400 (см. рисунок 4.6) устроен совсем иначе. У него, как и у обычных, есть набор команд с кодами операций и операндами. Есть в нем и разные типы арифметических операций (например, команды сложения) и операций передачи управления, работающие с традиционными операндами. Но в отличие от обычного интерфейса в нем есть команды, аналогичные промежуточному представлению, используемому в современных компиляторах ЯВУ, а также структуры данных (объекты).
Самое важное отличие не в самих командах или операциях, а в используемых ими операндах. В обычном интерфейсе есть регистры, память и непосредственные данные. На AS/400 мы попрежнему имеем непосредственные данные, но нет ни регистров, ни памяти. Их заменяют объекты.
В MI определены объекты нескольких типов. Большинство из них — сложные структуры данных, нужные для представления информационных ресурсов. Один из самых важных типов объектов в системе — пространство (просто набор байтов, не связанный с физическим оборудованием). Многие с трудом представляют себе массу подвешенных неизвестно где байтов, им хочется обязательно связать их с аппаратурой. Но в MI понятие пространства не имеет отношения к физической памяти, он абсолютно независим от того, что находится ниже2Специалисты по AS/400 любят рассуждать об одноуровневой памяти. Как мы только что убедились, в MI вообще нет памяти. Таким образом, одноуровневая память невидима или находится вне MI; скорее, это часть внутренней реализации AS/400..
Когда программе MI требуется память, она использует пространство. На этом уровне нет понятий регистров, физической памяти и адресов памяти в традиционном смысле. Например, компилятор AS/400 должен кудато деть созданный шаблон программы — в пространство!
Кроме пространств, существуют и другие типы объектов, которые мы обсудим далее. До сих пор мы обсуждали только системные объекты MI. Но объекты поддерживает и OS/400.
Работа с программами MI
Несколько команд MI работают с программами. Так как программа представляет собой объект, эти команды рассматривают программу целиком. Все команды выполняют над программой только операции, имеющие смысл. Есть команда создания программы, но нет команды перемножения программ, так как первая имеет смысл, а вторая — нет. Короче, команды специфичны для объектов того типа, с которым они манипулируют. Команды применяются к объекту целиком, а не к некоторым частям данных внутри объекта. Объект нельзя использовать не по назначению, так что еще одно крупное преимущество объектной ориентации — целостность. Программы в MI играют только присущую им роль. Давайте рассмотрим, как программа создается, уничтожается и материализуется.
Создание программы
Программа создается на основе шаблона — заранее описанной структуры со всеми характеристиками определенного системного объекта MI. Шаблон формируется частью компилятора AS/400, отвечающей за генерацию кода. Все системные объекты MI образуются по шаблонам, хранящимся в пространствах MI. Так как объектам разного типа присущи разные характеристики, единого общего шаблона нет — у каждого объекта свой уникальный шаблон.
Команда создания программы "Create Program" указывает на шаблон программы. Пока мы остановимся на двух типах указателей: системном и пространственном (позже мы увидим, что есть указатели и других типов). Первый направлен на системный объект MI, второй — на байт в пространстве. Длина каждого из этих указателей 16 байт. Через указатели в MI осуществляется адресация, так что указатель в MI можно представлять себе просто как адрес.
Команда создания программы исполняется с помощью кода, лежащего ниже MI. Сначала через пространственный указатель команды "Create Program" код находит шаблон программы, над которым выполняется синтаксический контроль. Затем транслятор преобразует последовательность команд MI-шаблона программы в последовательность внутренних команд IMPI или PowerPC, которая упаковывается в системный объект MI — программу. Наконец, инициатору запроса возвращается адрес вновь созданной программы в виде системного указателя на этот объект. Если в какойто части данной операции возникают проблемы, соответствующая диагностическая информация возвращается в виде сообщения.
Уничтожение программы
Любой объект на уровне MI, который можно создать, можно и уничтожить. Соответственно на каждую команду создания объектов MI приходится команда уничтожения. Пользователь на уровне MI устанавливает системный указатель на программу или другой объект MI и дает команду: "Уничтожить". Конечно, сделать это просто так нельзя: у пользователя должны быть соответствующие права на доступ к разным объектам.
Тему прав пользователей по отношению к объектам мы подробно обсудим в "Защита от несанкционированного доступа" , а сейчас только упомянем, что пользователь может иметь разные уровни прав доступа к разным объектам. Чтобы уничтожать объекты, нужен самый высокий уровень. Как правило, объект может уничтожить только его владелец; но бывают ситуации, когда такие права имеют несколько пользователей. Каждому пользователю в системе соответствует специальный объект — профиль пользователя. Вместе с другими объектами профиль пользователя определяет права данного пользователя по отношению к тем или иным объектам. Когда пользователь прибегает к команде уничтожения, система сначала обращается к его профилю и выясняет, есть ли у него такое право, и лишь в случае утвердительного ответа выполняет операцию.
Материализация и адаптируемость программы
Наблюдать характеристики программы поверх MI можно лишь через шаблон программы. Шаблон — результат работы компиляторов ЯВУ. Это самый нижний уровень, на котором возможна работа с компонентами программы поверх MI. Ниже MI программа существует в виде системного объекта, и все работающие с ним команды MI воспринимают его как единое целое.
Внутри объекта находится последовательность команд IMPI или PowerPC. Объект инкапсулирован, то есть, невидим извне. Это обеспечивает независимость от технологии, однако программа не имеет законченной формы, так как последовательность ее команд невидима.
Однако, если прикладному или системному ПО необходим доступ к характеристикам программы, команда MI, позволяет эту программу материализовать. Команда материализации указывает на инкапсулированный программный объект, по которому воссоздается шаблон программы. Материализация — операция, противоположная инкапсуляции.
Технологию материализации не всем просто понять. Честно говоря, обратная компиляция (восстановление исходного текста программы при наличии ее только в откомпилированном виде) не слишком хорошо разработана и многолетние исследования в этой области идут пока без особого успеха.
Как же решает эту задачу AS/400? Да просто жульничает: она не выполняет декомпиляции последовательности команд IMPI или PowerPC. Вместо этого копия шаблона программы сохраняется вместе с объектом. Когда выполняется команда MI материализующая программу, в ответ возвращается объект шаблона программы.
Хранение шаблона программы в качестве системного объекта MI и придает System/38 и AS/400 возможности, отсутствующие в других системах. Это позволяет изменять набор команд, не влияя на приложения заказчиков. Изменения вносятся в новую версию транслятора, а затем все программы ретранслируются из своих шаблонов. Наконец, новые последовательности команд снова инкапсулируются в объекты. Все это происходит ниже MI и без участия пользователя.
Чтобы Вы смогли лучше "почувствовать разницу", обратимся к классическому примеру внедрения System/38 Model 7. System/38 появилась как абсолютно новая система с абсолютно новым набором команд, новыми приложениями и новой ОС. Но как использовать эти команды, никто точно не знал. Как правило, для того, чтобы достичь максимальной производительности системы, оптимизируют аппаратную реализацию наиболее часто встречающихся последовательностей команд с целью достичь их как можно более быстрого выполнения.
Первоначально набор команд IMPI имел только 8битные коды операций, то есть команд не могло быть более 256 (28 = 256). Когда начали писать приложения для System/38, то обнаружилось, что нужны новые функции. В ответ мы изобретали новые команды (своего рода болезнь!) и очень скоро вышли за эти пределы.
Вполне естественно стремление сохранить набор операций небольшим, а следовательно, контролируемым и не избыточным. Но не менее законно желание упростить сложные задачи. Как увязать эти противоречия? Хорошо, если б существовал научный метод создания наборов команд, но, увы! Это скорее искусство, чем наука. Через пару лет мы пришли, как нам казалось, к оптимальному набору команд IMPI. И чтобы добавить эти новые команды, решили ввести в формат команд IMPI расширения кода операции.
К тому времени мы уже знали, как работать с существующими командами IMPI и как повысить производительность путем перевода наиболее часто используемых команд в другие, более быстрые форматы. Изменение кодов операций означает, что команда, на предыдущей версии оборудования вызывавшая, скажем, загрузку, на новой версии служит для передачи управления. В любой "нормальной" системе такая замена привела бы к хаосу, но не в System/38 — ведь она не зависит от технологии.
При модернизации оборудования системы устанавливалась и новая версия транслятора. У каждой программы в системе был свой заголовок объекта, который, кроме всего прочего, показывал, какой уровень транслятора использовался для создания программы. При первом исполнении программы система проверяла заголовок и при обнаружении старой версии обрабатывала связанный с объектом шаблон программы новым транслятором, сохраняя новый код IMPI в объекте. После этого программа выполнялась. Ретрансляция производится лишь однажды — при следующих вызовах программы используется новый код.
Тот же метод скрытой ретрансляции программ применялся при переходе на RISC-процессоры. Разница была лишь в том, что заказчиков заранее предупреждали, что приложения будут работать, только если не удалена адаптируемость. Что же изменилось со времен System/38?
AS/400 должна была привлечь и пользователей System/36, и System/38. Между тем вторые привыкли к большим объемам памяти и жестких дисков, так же как и пользователи System/36 — обходиться малым. Поэтому размеры новых программ последних пугали, и казались им чересчур большими.
Программы для AS/400 действительно впечатляли — ведь каждая хранилась в двух копиях: в инкапсулированной форме и в форме шаблона. Для экономии пространства на диске заказчики могли удалить шаблоны. Это называлось удалением адаптируемости программы (Delete Program Observability), так как после программу уже нельзя было материализовать.
В результате те, кто удалил адаптируемость некоторых или всех своих программ, должны были вернуться к исходным текстам на ЯВУ и заново откомпилировать их, прежде чем переносить на RISCпроцессоры. И хотя на AS/400 это все равно проще, чем на большинстве других систем, все же перенос не выполнялся автоматически, как при наличии программного шаблона.