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

Вы поражены прозорливостью разработчиков первоначальной архитектуры MI, раз и навсегда определивших набор API, используемый OS/400 и всеми приложениями? Не стоит: они не сделали этого, да и не могли сделать. По мере появления новых приложений в архитектуру MI добавлялись поддерживающие их новые API. Дело в том, что архитектура MI безразмерна, и новые API для поддержки новых приложений или функций операционной системы к ней можно добавлять в любое время. А раз эта архитектура постоянно изменяется, приобретая новые функции, то значит, она никогда не устареет. Так как все предыдущие API остаются при этом нетронутыми, для всех ранее написанных приложений сохраняется защита в границах MI.

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

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

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

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

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

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

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

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

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

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