Фрэнк Солтис - Основы AS/400

Наблюдать характеристики программы поверх 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 = 25 6). Когда начали писать приложения для System/38, то обнаружилось, что нужны новые функции. В ответ мы изобретали новые команды (своего рода болезнь!) и очень скоро вышли за эти пределы.

Вполне естественно стремление сохранить набор операций небольшим, а следовательно, контролируемым и не избыточным. Но не менее законно желание упростить сложные задачи. Как увязать эти противоречия? Хорошо, если б существовал научный метод создания наборов команд, но, увы! Это скорее искусство, чем наука. Через пару лет мы пришли, как нам казалось, к оптимальному набору команд IMPI. И чтобы добавить эти новые команды, решили ввести в формат команд IMPI расширения кода операции.

К тому времени мы уже знали, как работать с существующими командами IMPI и как повысить производительность путем перевода наиболее часто используемых команд в другие, более быстрые форматы. Изменение кодов операций означает, что команда, на предыдущей версии оборудования вызывавшая, скажем, загрузку, на новой версии служит для передачи управления. В любой «нормальной» системе такая замена привела бы к хаосу, но не в System/38 — ведь она не зависит от технологии.

При модернизации оборудования системы устанавливалась и новая версия транслятора. У каждой программы в системе был свой заголовок объекта, который, кроме всего прочего, показывал, какой уровень транслятора использовался для создания программы. При первом исполнении программы система проверяла заголовок и при обнаружении старой версии обрабатывала связанный с объектом шаблон программы новым транслятором, сохраняя новый код IMPI в объекте. После этого программа выполнялась. Ретрансляция производится лишь однажды — при следующих вызовах программы используется новый код.