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

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

Это работало блестяще, но... начались претензии заказчиков: «Я только что °—° установил систему, и мне кажется, что прикладные программы стали работать медленнее». Это и понятно: ретрансляция впервые запущенного приложения приводила к замедлению работы. Как Вы думаете, что мы отвечали? Конечно же — «Попробуйте еще раз». Тот же метод скрытой ретрансляции программ применялся при переходе на RISC-процессоры. Разница была лишь в том, что заказчиков заранее предупреждали, что приложения будут работать, только если не удалена адаптируемость. Что же изменилось со времен System/38?

AS/400 должна была привлечь и пользователей System/36, и System/38. Между тем вторые привыкли к большим объемам памяти и жестких дисков, так же как и пользователи System/36 — обходиться малым. Поэтому размеры новых программ последних пугали, и казались им чересчур большими.

Программы для AS/400 действительно впечатляли — ведь каждая хранилась в двух копиях: в инкапсулированной форме и в форме шаблона. Для экономии пространства на диске заказчики могли удалить шаблоны. Это называлось удалением адаптируемости программы (Delete Program Observability), так как после программу уже нельзя было материализовать.

В результате те, кто удалил адаптируемость некоторых или всех своих программ, должны были вернуться к исходным текстам на ЯВУ и заново откомпилировать их, прежде чем переносить на RISC-процессоры. И хотя на AS/400 это все равно проще, чем на большинстве других систем, все же перенос не выполнялся автоматически, как при наличии программного шаблона.

Внутри шаблона программы

Чтобы выяснить, что там происходит, возьмем в качестве примера шаблон программы ОРМ, хотя он и не поддерживается на RISC-системах. Я выбрал ОРМ по двум причинам. Во-первых, это дает возможность рассмотреть еще несколько интересных концепций, лежащих в основе оригинального набора команд MI. Во-вторых, некоторые детали шаблона программы ILE не опубликованы. И поэтому прежде чем заняться шаблоном программы ОРМ, рассмотрим те изменения, которые были внесены в программную модель ILE.

При создании компиляторов для программной модели ILE, в MI были добавлены новые команды. Некоторые из них имеют структуру близкую к W-коду, используемому компиляторами ILE, однако не совпадают с его командами в точности. Права на W-код принадлежат лаборатории IBM в Торонто (Toronto), Канада, которая пока не желает лицензировать интерфейс W-кода кому-либо за пределами IBM, опасаясь, что другие смогут разрабатывать и продавать компиляторы для AS/400. Мы решили определить команды! MI, которые похожи, но не в точности совпадают с W-кодом, чтобы не связываться с Торонто, если там когда-либо будет принято решение открыть этот интерфейс другим фирмам.

Наилучший целевой компьютер для компиляторов ILE — стековая машина, поэтому MI был расширен для поддержки стеков. Стек — набор данных, хранящихся последовательно. Первый помещенный в стек элемент называется его дном, последний — вершиной. Для работы со стеком используются команды без явного указания операндов, которые определяются путем извлечения из стека двух верхних элементов. В противоположность этому, команды ОРМ имеют два операнда, заданных непосредственно в команде. Для стековой машины операция задается после операндов. Такая форма записи называется постфиксной или обратной польской в честь математика Лукашевича (J. Lukasiewicz), исследовавшего ее свойства[ 37 ].

Интересно, что архитектура, разработанная в 1972 году, имела аналогичную поддержку стека. В то время многие полагали, что блочно-структурированные языки, такие как PL/1, станут очень популярными. Но они так и не вытеснили RPG и Cobol, так что стек был временно отвергнут. Теперь, с появлением таких языков как С, мы снова вернулись к нему.

Рисунок 4.7 Команды и ODT

Шаблон программы состоит из нескольких частей. Шаблон программы ОРМ содержит заголовок, последовательность команд MI, пользовательские данные и структуру под названием таблица определения объектов ODT (object definition table). Команды и ODT представлены на рисунке 4.7. Последовательность команд на рисунке содержит пример команды MI. Использована классическая команда OPM с тремя операндами —арифметическое сложение. Она состоит из кода операции, за которым следуют три значения, используемые для поиска трех операндов. Каждое из них является индексом в ODT. Показанная на рисунке команда запрашивает сложение операнда 6 с операндом 2 и помещение суммы в операнд 3.

ODT состоит из двух компонентов. Первая — ODV (ODT Direction Vector) — содержит по одному элементу для каждого операнда программы. Все элементы имеют одинаковую длину, так что значение из последовательности команд может использоваться как индекс в ODV. Элементы ODV описывают операнды. В нашем примере, операнды 6 и 3 — это двоичные числа длиной 2 байта, а операнд 2 — константа. Константы и другие типы операндов могут иметь переменную длину, что задает необходимость второго компонента ODT. OES (ODT Entry String) содержит операнды переменной длины, не умещающиеся в ODV. Содержимое поля ODV указывает на начало цепочки в OES. В нашем примере операнд 2 представляет собой константу 1253.

Пример иллюстрирует несколько характеристик команд MI модели ОРМ. Во-первых — это команда арифметического сложения. Это не команда двоичного или десятичного сложения, или сложения с плавающей запятой; она универсальна. Формат операндов команды определяется в ODT. В нашем примере используются двоичные целые операнды, но они могли бы иметь любой числовой формат. За генерацию необходимых преобразований отвечает транслятор.

Во-вторых, из примера видно, что ОРМ MI — неисполняемый интерфейс. Обратите внимание, что ни с операндом 3, ни с операндом 6 не связаны значения. Элемент ODV эквивалентен объявлению переменной. Память для переменной не выделена, так что транслятор обязан завершить компиляцию и назначить переменным регистры или области памяти.

И, наконец, в примере показана обычная вычислительная команда. Команда, работающая с объектом, имела бы аналогичный формат, но в ODT было бы указано, как найти объект (детали адресации объектов будут рассмотрены в главе 5).