Основы AS/400

При модернизации оборудования системы устанавливалась и новая версия транслятора. У каждой программы в системе был свой заголовок объекта, который, кроме всего прочего, показывал, какой уровень транслятора использовался для создания программы. При первом исполнении программы система проверяла заголовок и при обнаружении старой версии обрабатывала связанный с объектом шаблон программы новым транслятором, сохраняя новый код 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