ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.12.2021
Просмотров: 6179
Скачиваний: 6
Многоуровневая компьютерная организация 23
Второй уровень мы будем называть уровнем архитектуры системы команд.
Каждый производитель публикует руководство для компьютеров, которые он про-
дает, под названием «Руководство по машинному языку» или «Принципы работы
компьютера Western Wombat Model 100X» и т. п. Такие руководства содержат
информацию именно об этом уровне. Когда они описывают набор машинных ко-
манд, они в действительности описывают команды, которые выполняются микро-
программой-интерпретатором или аппаратным обеспечением. Если производитель
поставляет два интерпретатора для одной машины, он должен издать два руковод-
ства по машинному языку, отдельно для каждого интерпретатора.
Следующий уровень обычно гибридный. Большинство команд в его языке есть
также и на уровне архитектуры системы команд (команды, имеющиеся на одном
из уровней, вполне могут находиться на других уровнях). У этого уровня есть не-
которые дополнительные особенности: набор новых команд, другая организация
памяти, способность выполнять две и более программ одновременно и некоторые
другие. При построении третьего уровня возможно больше вариантов, чем при
построении первого и второго.
Новые средства, появившиеся на третьем уровне, выполняются интерпретато-
ром, который работает на втором уровне. Этот интерпретатор был когда-то назван
операционной системой. Команды третьего уровня, идентичные командам второ-
го уровня, выполняются микропрограммой или аппаратным обеспечением, но не
операционной системой. Иными словами, одна часть команд третьего уровня ин-
терпретируется операционной системой, а другая часть — микропрограммой. Вот
почему этот уровень считается гибридным. Мы будем называть этот уровень
уров-
нем операционной системы.
Между третьим и четвертым уровнями есть существенная разница. Нижние три
уровня конструируются не для того, чтобы с ними работал обычный программист.
Они изначально предназначены для работы интерпретаторов и трансляторов, под-
держивающих более высокие уровни. Эти трансляторы и интерпретаторы составля-
ются так называемыми
системными программистами,
которые специализируются
на разработке и построении новых виртуальных машин. Уровни с четвертого и выше
предназначены для прикладных программистов, решающих конкретные задачи.
Еще одно изменение, появившееся на уровне 4, — способ, которым поддержи-
ваются более высокие уровни. Уровни 2 и 3 обычно интерпретируются, а уровни 4,
5 и выше обычно, хотя и не всегда, поддерживаются транслятором.
Другое различие между уровнями 1,2,3 и уровнями 4,5 и выше — особенность
языка. Машинные языки уровней 1,2 и 3 — цифровые. Программы, написанные на
этих языках, состоят из длинных рядов цифр, которые удобны для компьютеров,
но совершенно неудобны для людей. Начиная с четвертого уровня, языки содер-
жат слова и сокращения, понятные человеку.
Четвертый уровень представляет собой символическую форму одного из язы-
ков более низкого уровня. На этом уровне можно писать программы в приемлемой
для человека форме. Эти программы сначала транслируются на язык уровня 1, 2
или 3, а затем интерпретируются соответствующей виртуальной или фактически
существующей машиной. Программа, которая выполняет трансляцию, называет-
ся
ассемблером.
24 Глава 1. Предисловие
Пятый уровень обычно состоит из языков, разработанных для прикладных про-
граммистов. Такие языки называются
языками высокого уровня.
Существуют
сотни языков высокого уровня. Наиболее известные среди них — BASIC, С, C++,
Java, LISP и Prolog. Программы, написанные на этих языках, обычно транслиру-
ются на уровень 3 или 4. Трансляторы, которые обрабатывают эти программы, на-
зываются
компиляторами.
Отметим, что иногда также используется метод интер-
претации. Например, программы на языке Java обычно интерпретируются.
В некоторых случаях пятый уровень состоит из интерпретатора для такой сферы
приложения, как символическая математика. Он обеспечивает данные и операции
для решения задач в этой сфере в терминах, понятных людям, сведущим в симво-
лической математике.
Вывод: компьютер проектируется как иерархическая структура уровней, каж-
дый из которых надстраивается над предыдущим. Каждый уровень представляет
собой определенную абстракцию с различными объектами и операциями. Рассмат-
ривая компьютер подобным образом, мы можем не принимать во внимание не-
нужные нам детали и свести сложный предмет к более простому для понимания.
Набор типов данных, операций и особенностей каждого уровня называется ар-
хитектурой. Архитектура связана с аспектами, которые видны программисту. На-
пример, сведения о том, сколько памяти можно использовать при написании про-
граммы, — часть архитектуры. А аспекты разработки (например, какая технология
используется при создании памяти) не являются частью архитектуры. Изучение
того, как разрабатываются те части компьютерной системы, которые видны програм-
мистам, называется изучением
компьютерной архитектуры.
Термины «компью-
терная архитектура» и «компьютерная организация» означают в сущности одно
и то же.
Развитие многоуровневых машин
В этом разделе мы кратко изложим историю развития многоуровневых машин,
покажем, как число и природа уровней менялись с годами. Программы, написан-
ные на машинном языке (уровень 1), могут сразу выполняться электронными
схемами компьютера (уровень 0), без применения интерпретаторов и транслято-
ров. Эти электронные схемы вместе с памятью и средствами ввода-вывода форми-
руют
аппаратное обеспечение.
Аппаратное обеспечение состоит из осязаемых
объектов — интегральных схем, печатных плат, кабелей, источников электропита-
ния, запоминающих устройств и принтеров. Абстрактные понятия, алгоритмы
и команды не относятся к аппаратному обеспечению.
Программное обеспечение,
напротив, состоит из алгоритмов (подробных по-
следовательностей команд, которые описывают, как решить задачу) и их компью-
терных представлений, то есть программ. Программы могут храниться на жестком
диске, гибком диске, компакт-диске или других носителях, но в сущности программ-
ное обеспечение — это набор команд, составляющих программы, а не физические
носители, на которых эти программы записаны.
В самых первых компьютерах граница между аппаратным и программным обес-
печением была очевидна. Со временем, однако, произошло значительное размы-
вание этой границы, в первую очередь благодаря тому, что в процессе развития
Многоуровневая компьютерная организация 25
компьютеров уровни добавлялись, убирались и сливались. В настоящее время очень
сложно отделить их друг от друга. В действительности центральная тема этой
книги может быть выражена так:
аппаратное и программное обеспечение логически
эквивалентны.
Любая операция, выполняемая программным обеспечением, может быть встро-
ена в аппаратное обеспечение (желательно после того, как она осознана). Карен
Панетта Ленц говорил; «Аппаратное обеспечение — это всего лишь окаменевшее
программное обеспечение». Конечно, обратное тоже верно: любая команда, выпол-
няемая аппаратным обеспечением, может быть смоделирована в программном обес-
печении. Решение разделить функции аппаратного и программного обеспечения
основано на таких факторах, как стоимость, скорость, надежность, а также частота
ожидаемых изменений. Существует несколько жестких правил, сводящихся к тому,
что X должен быть в аппаратном обеспечении, a Y должен программироваться.
Эти решения изменяются в зависимости от тенденций в развитии компьютерных
технологий.
Изобретение микропрограммирования
У первых цифровых компьютеров в 1940-х годах было только 2 уровня: уровень
архитектуры набора команд, на котором осуществлялось программирование, и циф-
ровой логический уровень, который выполнял программы. Схемы цифрового
логического уровня были сложны для производства и понимания и ненадежны.
В 1951 году Морис Уилкс, исследователь Кембриджскс-о университета, пред-
ложил идею разработки трехуровневого компьютера для того, чтобы упростить
аппаратное обеспечение [158]. Эта машина должна была иметь встроенный неиз-
меняемый интерпретатор (микропрограмму), функция которого заключалась
в выполнении программ посредством интерпретации. Так как аппаратное обеспе-
чение должно было теперь вместо программ уровня архитектуры команд выпол-
нять только микропрограммы с ограниченным набором команд, требовалось мень-
шее количество электронных схем. Поскольку электронные схемы тогда делались
из электронных ламп, такое упрощение должно было сократить количество ламп
и, следовательно, увеличить надежность.
В 50-е годы было построено несколько трехуровневых машин. В 60-х годах число
таких машин значительно увеличилось. К 70-м годам идея о том, что написанная
программа сначала должна интерпретироваться микропрограммой, а не выполнять-
ся непосредственно электроникой, стала преобладающей.
Изобретение операционной системы
В те времена, когда компьютеры только появились, принципы работы с ними сильно
отличались от современных. Одним компьютером пользовалось большое количе-
ство людей. Рядом с машиной лежал листок бумаги, и если программист хотел
запустить свою программу, он записывался на какое-то определенное время, ска-
жем, на среду с 3 часов ночи до 5 утра (многие программисты любили работать
в тишине). В назначенное время программист направлялся в комнату, где стояла
машина, с пачкой перфокарт, которые тогда служили средством ввода, и каранда-
шом. Каждая перфокарта содержала 80 колонок; на ней в определенных местах
26 Глава 1 Предисловие
пробивались отверстия. Войдя в комнату, программист вежливо просил предыду-
щего программиста освободить место и приступал к работе.
Если он хотел запустить программу на языке FORTRAN, ему необходимо было
пройти следующие этапы:
1. Он подходил к шкафу, где находилась библиотека программ, брал большую
зеленую стопку перфокарт с надписью «Компилятор FORTRAN», помещал
их в считывающее устройство и нажимал кнопку «Пуск».
2. Затем он помещал стопку карточек со своей программой, написанной на язы-
ке FORTRAN, в считывающее устройство и нажимал кнопку «Продолжить».
Программа считывалась.
3. Когда компьютер прекращал работу, программист считывал свою програм-
му во второй раз. Некоторые компиляторы требовали только одного считы-
вания перфокарт, но в большинстве случаев необходимо было производить
эту процедуру несколько раз. Каждый раз нужно было считывать большую
стопку перфокарт.
4. В конце концов трансляция завершалась. Программист часто становился
очень нервным, потому что если компилятор находил ошибку в программе,
ему приходилось исправлять ее и начинать процесс ввода программы зано-
во. Если ошибок не было, компилятор выдавал программу на машинном язы-
ке на перфокартах.
5. Тогда программист помещал эту программу на машинном языке в устрой-
ство считывания вместе с пачкой перфокарт из библиотеки подпрограмм и
загружал обе эти программы.
6. Начиналось выполнение программы. В большинстве случаев она не работа-
ла или неожиданно останавливалась в середине. Обычно в этом случае про-
граммист начинал дергать переключатели на пульте и смотрел на лампочки.
В случае удачи он находил и исправлял ошибку, подходил к шкафу, в кото-
ром лежал большой зеленый компилятор FORTRAN, и начинал все заново.
В случае неудачи он делал распечатку содержания памяти, что называлось
разгрузкой оперативного запоминающего устройства,
и брал эту распечатку
домой для изучения.
Это процедура была обычной на протяжении многих лет. Программистам при-
ходилось учиться, как работать с машиной и что нужно делать, если она выходила
из строя, что происходило довольно часто. Машина постоянно простаивала без
работы, пока люди носили перфокарты по комнате или ломали головы над тем,
почему программа не работает.
В 60-е годы человек попытался сократить количество потерянного времени,
автоматизировав работу оператора. Программа под названием
«операционная
система»
теперь содержалась в компьютере все время. Программист приносил
пачку перфокарт со специальной программой, которая выполнялась операцион-
ной системой. На рисунке 1.3 показана модель пачки перфокарт для первой широ-
ко распространенной операционной системы FMS (FORTRAN Monitor System)
к компьютеру IBM-709.
Многоуровневая компьютерная организация
27
'JOB, 5494, BARBARA
"XEQ
•FORTRAN
Программа
на FORTRAN
•DATA
Перфокарты
с данными
•END
Рис. 1.3. Схема работы с операционной системой FMS
Операционная система считывала перфокарту *JOB и использовала содержа-
щуюся на ней информацию для учета системных ресурсов (звездочка ставилась,
чтобы отличать перфокарты с программой контроля от перфокарт с данными).
Затем операционная система считывала перфокарту *FORTRAN, которая пред-
ставляла собой команду для загрузки компилятора FORTRAN с магнитной лен-
ты. После этого компилятор считывал и компилировал программу, написанную
на языке FORTRAN. Как только компилятор заканчивал работу, операционная
система считывала перфокарту *DATA — команду по выполнению транслирован-
ной программы с использованием перфокарт данных.
Операционная система была придумана для того, чтобы автоматизировать
работу оператора (отсюда и название), но это не единственное ее назначение.
Создание операционной системы было первым шагом в развитии новой вирту-
альной машины. Перфокарту *FORTRAN можно рассматривать как виртуальную
команду к компилятору, а перфокарту *DATA — как виртуальную команду для
выполнения программы. И хотя этот уровень состоял всего из двух команд, он был
первым этапом в развитии виртуальных машин.
В последующие годы операционные системы все больше и больше усложня-
лись. К уровню архитектуры команд добавлялись новые команды, приспособле-
ния
и
особенности, и в итоге сформировался новый уровень. Некоторые команды
нового уровня были идентичны командам предыдущего, но другие (в частности
команды ввода-вывода) полностью отличались. Эти новые команды тогда назы-
вались
макросами операционной системы
или
вызовами супервизора.
Сейчас
обычно используется термин
«системный вызов».
Первые операционные системы считывали пачки перфокарт и распечатывали
результат на принтере. Такая организация вычислений называлась
пакетным