Реклама:

В этом разделе мы кратко расскажем об истории развития многоуровневых машин, покажем, как количество и природа уровней менялись с годами. Программы, написанные на машинном языке (уровень 1), могут сразу без применения интерпретаторов и трансляторов выполняться электронными схемами компьютера (уровень 0). Эти электронные схемы вместе с памятью и средствами ввода-вывода формируют аппаратное обеспечение. Аппаратное обеспечение состоит из осязаемых объектов - интегральных схем, печатных плат, кабелей, источников электропитания, модулей памяти и принтеров. Абстрактные понятия, алгоритмы и команды к аппаратному обеспечению не относятся.

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

В самых первых компьютерах граница между аппаратным и программным обеспечением была очевидна. Со временем, однако, произошло значительное размывание этой границы, в первую очередь благодаря тому, что в процессе развития компьютеров уровни добавлялись, убирались и сливались друг с другом. В настоящее время очень сложно отделить их друг от друга [213]. С этой проблемой связана центральная тема нашей книги:

Аппаратное и программное обеспечение логически эквивалентны

Любая операция, выполняемая программным обеспечением, может быть реализована аппаратным обеспечением (желательно после того, как она будет продумана). Карен Панетта Ленц (Karen Panetta Lentz) говорил: "Аппаратное обеспечение - это всего лишь окаменевшее программное обеспечение". Конечно, обратное тоже верно: любая команда, выполняемая аппаратным обеспечением, может быть смоделирована программно. Решение разделить функции аппаратного и программного обеспечения основано на таких факторах, как стоимость, быстродействие, надежность, частота ожидаемых изменений. Существует несколько жестких правил, сводящихся к тому, что операция X должна быть реализована в аппаратном обеспечении, а операцию У нужно программировать. Эти решения меняются в зависимости от тенденций экономического и технологического развития.

Изобретение микропрограммирования

У первых цифровых компьютеров в 40-х годах было только два уровня: уровень архитектуры набора команд, на котором осуществлялось программирование, и цифровой логический уровень, выполнявший программы. Схемы цифрового логического уровня были ненадежны, сложны для производства и понимания.

В 1951 году Морис Уилкс (Maurice Wilkes), исследователь Кембриджского Университета, предложил идею разработки трехуровневого компьютера, призванную упростить аппаратное обеспечение [219]. Эта машина должна была иметь встроенный неизменяемый интерпретатор (микропрограмму), функция которого заключалась в выполнении программ уровня ISA посредством интерпретации. Так как аппаратное обеспечение должно было теперь вместо программ уровня ISA выполнять только микропрограммы с ограниченным набором команд, требовалось меньшее количество электронных схем. Поскольку электронные схемы тогда делались из электронных ламп, данное упрощение призвано было сократить количество ламп и, следовательно, повысить надежность (которая в то время выражалась числом поломок за день).

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

Изобретение операционной системы

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

Если он хотел запустить программу на языке FORTRAN, ему необходимо было пройти следующие этапы:

1. Он подходил к шкафу, где находилась библиотека программ, брал большую зеленую стопку перфокарт с надписью "Компилятор FORTRAN", помещал их в считывающее устройство и нажимал кнопку "Пуск".

2. Он помещал стопку карточек со своей программой, написанной на языке FORTRAN, в считывающее устройство и нажимал кнопку "Продолжить". Программа считывалась.

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

4. В конце концов трансляция завершалась. Программист часто становился очень нервным, потому что если компилятор находил ошибку в программе, ему приходилось исправлять ее и начинать процесс ввода программы заново. Если ошибок не было, компилятор выдавал в виде перфокарт программу на машинном языке.

5. Тогда программист помещал эту программу на машинном языке в устройство считывания вместе с пачкой перфокарт из библиотеки подпрограмм и загружал обе эти программы.

6. Начиналось выполнение программы. В большинстве случаев она не работала, неожиданно останавливаясь в середине. Обычно в этом случае программист начинал дергать переключатели на пульте и смотрел на лампочки. В случае удачи он находил и исправлял ошибку, подходил к шкафу, в котором лежала большая зеленая стопка перфокарт с надписью "Компилятор FORTRAN", и начинал все заново. В случае неудачи он делал распечатку содержания памяти, что называлось разгрузкой оперативного запоминающего устройства, и брал эту распечатку домой для изучения.

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

В 60-е годы человек попытался ускорить дело, автоматизировав работу оператора. Программа под названием операционная система загружалась в компьютер на все время его работы. Программист приносил пачку перфокарт со специализированной программой, которая выполнялась операционной системой. На рис. 1.3 показана модель пачки перфокарт для первой широко распространенной операционной системы FMS (FORTRAN Monitor System) к компьютеру 709 компании IBM.

Развитие многоуровневых машин

Рис. 1.3. Схема работы с операционной системой FMS

Операционная система считывала перфокарту *JOB и использовала содержащуюся на ней информацию для учета системных ресурсов (звездочка ставилась, чтобы отличать перфокарты с управляющей программой от перфокарт с данными). Затем операционная система считывала перфокарту *FORTRAN, которая представляла собой команду для загрузки компилятора FORTRAN с магнитной ленты. После этого компилятор считывал и компилировал программу, написанную на языке FORTRAN. Как только компилятор заканчивал работу, операционная система считывала перфокарту *ДАННЫЕ - команду по выполнению транслированной программы с использованием перфокарт данных.

Операционная система была придумана для того, чтобы автоматизировать работу оператора (отсюда и название), но это - не единственное ее преимущество. Создание операционной системы было первым шагом в развитии новой виртуальной машины. Перфокарту * FORTRAN можно рассматривать как виртуальную команду к компилятору, а перфокарту *ДАННЫЕ - как виртуальную команду для выполнения программы. И хотя этот уровень состоял всего из двух команд, он стал первым шагом в развитии виртуальных машин.

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

Первые операционные системы считывали пачки перфокарт и распечатывали результат на принтере. Такая организация вычислений называлась пакетным режимом. Чтобы получить результат, обычно нужно было ждать несколько часов. При таких условиях было трудно развивать программное обеспечение.

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

Хотя нас интересуют только те компоненты операционной системы, которые интерпретируют команды третьего уровня, необходимо понимать, что это - не единственная функция операционных систем.

Смещение функциональности на уровень микрокода

С 1970 года, когда получило развитие микропрограммирование, у производителей появилась возможность вводить новые машинные команды расширением микропрограммы, то есть путем программирования. Это открытие привело к виртуальному взрыву в производстве программ машинных команд, поскольку производители начали конкурировать друг с другом, стараясь выпустить лучшие программы. Эти команды не представляли особой ценности, поскольку те же задачи можно было легко решить, используя уже существующие программы, но обычно они работали немного быстрее. Например, во многих компьютерах использовалась команда INC (INCrement), которая прибавляла к числу единицу. Тогда уже существовала общая команда сложения ADD, и не было необходимости вводить новую команду, прибавляющую к числу единицу. Тем не менее команда INC работала немного быстрее, чем ADD, поэтому ее также включили в набор команд.

Многие программы были добавлены в микропрограмму по той же причине. Среди них можно назвать команды:

4- для умножения и деления целых чисел;

4- арифметических действий над числами с плавающей точкой;

4- вызова и прекращения действия процедур;

4- ускорения циклов;

4- работы с символьными строками.

Как только производители поняли, что добавлять новые команды очень легко, они начали думать, какими дополнительными техническими возможностями можно наделить микропрограмму. Приведем несколько примеров:

4- ускорение работы с массивами (индексная и косвенная адресация);

4- перемещение программы из одного раздела памяти в другой после запуска программы (настройка);

4- системы прерывания, которые дают сигнал процессору, как только закончена операция ввода или вывода;

4- способность приостановить одну программу и начать другую, используя небольшое число команд (переключение процесса);

4- специальные команды для обработки изображений, звуковых и мультимедийных данных.

В дальнейшем дополнительные команды и технические возможности вводились также для ускорения работы компьютеров.

Конец микропрограммирования

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

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

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

Современные многоуровневые машины || Оглавление || Развитие компьютерной архитектуры