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

• Название: Основы AS/400
• Автор: Фрэнк Солтис
• Издательство: Русская Редакция
• Жанр: Программное обеспечение
• Год: 1998
• ISBN: 5-7502-0038-8

В данном переводе второго издания книги "Основы AS/400" описаны практически все аспекты работы этой вычислительной системы: от используемых в ней новейших аппаратных и программных технологий до истории создания. Издание состоит из предисловия, введения, 12 глав, приложения и предметного указателя; содержит иллюстрации. Автор книги Фрэнк Солтис, сделавший академическую карьеру в области информатики, начиная с замысла System/38, является одним из ведущих специалистов по идеологии и архитектуре AS/400. Книга предназначена для широкого круга читателей: бизнесменов, менеджеров, руководителей подразделений, желающих понять, чем система или сервер AS/400e могут быть выгодны их бизнесу. Тем не менее, издание будет полезно и специалистам, которые хотят разобраться в мельчайших деталях. На русском языке публикуется впервые.

---

Для большинства программистов язык ассемблера — также не вполне естественный, поэтому был создан еще более высокий уровень абстракции — язык программирования высокого уровня (ЯВУ). В настоящее время насчитываются сотни таких языков; наиболее известные из них — Basic, C, C++, Cobol и RPG. Программа, принимающая на входе текст на одном из языков высокого уровня и транслирующая его в операторы языка ассемблера, называется компилятором.

Иллюстрация многоуровневой абстракции — написание программы на языке высокого уровня. Компилятор выполняет преобразование программы на ЯВУ в язык ассемблера, который затем переводит свои команды в двоичный код, понятный процессору. Замечу, что некоторые компиляторы генерируют команды непосредственно на машинном языке, минуя уровень ассемблера.

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

Многоуровневая концепция может также использоваться и в аппаратуре компьютера. Многие процессоры, в том числе из семейства Intel, используют микропрограммирование. В микропрограммируемой машине применяется набор команд еще более низкого уровня. Для отображения между верхним и нижним уровнями микропрограммирование использует эмуляцию. При этом машинные команды выбираются и исполняются по одной, как последовательность команд более низкого уровня. Для преобразования машинных команд в форму, приемлемую для микропрограммы, не требуется отдельный этап компиляции.

Похожа на эмуляцию интерпретация программ. Программа-интерпретатор выбирает инструкции по одной и исполняет эквивалентную им последовательность команд более низкого уровня. Некоторые из новейших ЯВУ, используемых в распределенных вычислениях, например Java, разработаны так, чтобы их было легко интерпретировать. Большинство командных языков также интерпретируемы. Введите «dir» в командной строке DOS на любом ПК и на экране появится содержимое каталога. Если после этого нажать клавишу Enter, интерпретатор командной строки DOS считает введенную команду, а затем выполнит последовательность инструкций, необходимых для ее выполнения. Такой интерпретатор команд есть в большинстве операционных систем. В микропрограммируемой машине интерпретация обычно поддерживается специальным оборудованием. Микропрограмма для различения такой аппаратной формы интерпретации называется эмулятором.

Обычно архитектура набора команд вычислительной системы рассматривается как интерфейс между аппаратурой и программным обеспечением самого нижнего уровня. В те времена, когда Хассон сформулировал упоминавшееся выше определение архитектуры компьютера, программирование еще не использовало ЯВУ. Сегодня, более подходящим определением этого понятия было бы «характеристики системы с точки зрения компилятора», так как из нынешних программистов лишь немногие имеют дело с программами в машинных кодах.

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

Создание программ

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

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

Теперь же появилось много приверженцев мнения, что программирование на языке ассемблера — реликт прошлого. Но это не так. Большинство используемых ныне операционных систем (не только старых, чьи корни которых восходят к 60-м и началу 70-х годов, но и более современных) включают в себя большие объемы кода на ассемблере. Таковы, например, операционные системы для ПК: Windows 95 фирмы Microsoft написана по большей части на языке ассемблера Intel.

Первые процессоры для ПК имели достаточно ограниченные возможности. Максимальный размер памяти был равен 64 килобайтам. (Один килобайт равен 210 или 1024 байтам. Байт — это 8-разрядная ячейка памяти, в которой может храниться символ или цифра). Память стоила настолько дорого, что операционные системы могли занимать не более 4 килобайт. Язык ассемблера позволял программистам максимально сокращать размер кода. В результате на нем написан такой большой объем операционных систем, что даже когда размер доступной памяти увеличился благодаря удешевлению технологии, возвращаться назад и переписывать оригинальный код оказалось непрактичным.

Использование ассемблера действительно позволяет оптимизировать размеры и производительность программ. Тем не менее, у этой технологии, по крайней мере, один существенный недостаток: все программы напрямую привязаны к аппаратуре. Любое ее изменение может вызвать необходимость переписать некоторые или даже все программы.

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

Теперь предположим, что технологический прогресс позволил конструкторам увеличить количество регистров до 16 и сделать их 32-разрядными, причем стоит все это столько же, сколько и оригинальные 8 регистров меньшего размера. Зададимся вопросом: «Как это повлияет на программы, написанные для старого компьютера?». Ответ зависит от того, каким образом были сделаны изменения, и сколь хорошо первоначальная архитектура была спланирована для расширения в будущем.

Допустим, что в старой архитектуре предполагалось расширение до 16 регистров. В каждой команде было зарезервировано достаточно места для адресации 16 регистров, хотя первоначально были реализованы только 8. Для каждой команды, использующей регистры, в данном случае понадобились бы 4-разрядные поля, так как 4 бита позволяют закодировать 16 различных комбинаций нулей и единиц. На новом оборудовании старые программы могут выполняться без изменений. При этом они по-прежнему будут использовать только 8 регистров, новые же программы смогут воспользоваться всеми 16-ю.

А теперь представим себе вместо этого, что в старой архитектуре не были учтены будущие изменения и место для расширения не зарезервировано. Тогда новая архитектура не сможет увеличить количество регистров, не изменив при этом каждую команду, которая их использует. Невозможно растянуть трехбитовые поля в командах до 4 бит, не затронув при этом в той или иной степени существующие программы.

Одна из многих архитектур, неспособных увеличить число пользовательских регистров, — Intel Pentium Pro. Она использует то же количество регистров, что и ее предшественник Intel 386. Хотя увеличение числа регистров дало бы Pentium Pro преимущества, но затраты на переписывание существующих ассемблерных программ слишком велики.

Вообще, увеличение размера регистров с 16 до 32 разрядов оказывает меньшее влияние, чем изменение их количества. Если увеличился только размер, то старые программы будут по-прежнему работать, но использовать лишь 16 из 32 разрядов новых регистров. Данная информация внедрена в логику программы, и ее трудно изменить[ 7 ].