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

Компьютер обычно представляет свои информационные ресурсы — каталоги, файлы баз данных и описания физических устройств — в виде структур данных или хранящихся в памяти блоков с заранее определенными полями. Приложения и системное ПО, обладая непосредственным доступом к этим структурам данных, манипулируют их полями. А следовательно, они должны «знать», как это делать.

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

Благодаря использованию объектов, прикладному и системному ПО больше не требуется информация о структуре или формате данных. Эта информация хранится в контейнере и невидима за пределами объекта. Поэтому любые изменения в структуре данных не влияют на прикладные или системные программы, и они остаются независимыми от структур нижнего уровня. Такое свойство сокрытия внутренних деталей называется инкапсуляцией. Мы обсудим инкапсуляцию, а также внутреннюю структуру объекта и команды для работы с ними в главе 5, а теперь сосредоточимся на наборе команд архитектуры MI.

Давайте обсудим несколько примеров команд, выполняемых над обычными данными и команд, оперирующих объектами. Поговорим и о том, как компиляторы используют MI для генерации кода, выполняемого аппаратурой, познакомимся с характеристиками MI и программами MI. И наконец, рассмотрим структуру команд MI.

Команды MI не исполняются аппаратурой непосредственно. Они либо предварительно (до исполнения программы) транслируются в аппаратный набор команд, либо специальный компонент SLIC интерпретирует некоторые команды MI одну за другой. Пример интерпретируемых команд MI — API Advanced 36. Мы называем процесс преобразования команд MI в низкоуровневые аппаратные команды трансляцией, а не компиляцией, так как при этом выполняется лишь часть функций компиляции. Прежде результатом такой трансляции был набор инструкций IMPI — теперь это набор инструкций PowerPC.

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

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

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

Возможности однопроходного компилятора по оптимизации ограничены. Проще говоря, он не может просмотреть код программы вперед и учесть то, что произойдет дальше. «Заглянуть вперед» может многопроходный компилятор. Назначение регистров переменным в зависимости от их связей с другими переменными, запись в память ненужного более содержимого кэша, предварительная выборка операндов — вот лишь некоторые примеры оптимизации, выполняемой многопроходным компилятором.

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

Рисунок 4.1 Структура оптимизирующего компилятора

Первый проход компилятора, показанного на рис. 4.1, часто называют препроцессором (front end) компилятора. Его задача — преобразование текста на ЯВУ в общую промежуточную форму (common intermediate form).

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

Набор команд MI аналогичен общей промежуточной форме, применяемой в компиляторах. Компилятор ЯВУ преобразует исходный текст в форму для MI. Транслятор, расположенный уровнем ниже MI, считывает программу в этой форме, выполняет оптимизацию и генерирует инструкции IMPI или PowerPC. Транслятор очень напоминает постпроцессор компилятора.

Общая промежуточная форма для некоторых языков может как транслироваться, так и интерпретироваться. В главе 11 мы рассмотрим язык Java, использующий как раз такую форму. Промежуточная форма Java, известная как байт-код, также включена в MI.

Набор инструкций MI заменяет общую промежуточную форму не во всех компиляторах AS/400 — некоторые языки имеют собственную промежуточную форму. Ниже приводится описание внутренней структуры компиляторов языков для AS/400, и место MI в этой структуре.

Ранние компиляторы (например, RPG/400 и языка управления CL) для System/38 и AS/400 генерировали команды: MI довольно прямолинейно. Хотя они и проходили уровень ассемблера, в самом компиляторе не было общей промежуточной формы. Ее роль выполняли команды MI.

Модель программы для этих языков, включая форму программы ниже уровня MI, называется исходной моделью программ или OPM (Original Program Model). Позднее, для языков типа C/400, была добавлена расширенная модель программ или EPM (Extended Program Model). На рисунке 4.2 показан процесс генерации кода IMPI для OPM и ЕРМ. Мы представили здесь эти две модели только для демонстрации эволюции компиляторов AS/400. На RISC-системах версии 4 не используются ни компиляторы ОРМ, ни ЕРМ.