Материал: Tannenbaum

Разработка микроархитектурного уровня 273

больше микросхема. И стоимость микросхемы растет гораздо быстрее, чем зани-

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

В истории компьютерной промышленности одной из наиболее тщательно про-

работанных микросхем является двоичный сумматор. Были реализованы тысячи

проектов, и самые быстрые двоичные сумматоры очень сильно превышают по ско-

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

Сумматор — не единственный компонент, допускающий различные варианты

разработки. Практически любой компонент системы может быть спроектирован

таким образом, что

 он

 будет функционировать с более высокой или с более низкой

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

Главной задачей разработчика является определение тех компонентов системы,

усовершенствование которых может максимально повлиять на скорость работы

компьютера. Интересно отметить, что если какой-нибудь компонент заменить бо-

лее быстрым, это не обязательно повлечет за собой повышение общей производи-

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

Одним из ключевых факторов в определении скорости работы генератора

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

длиннее цикл. Однако все не так просто, ведь аппаратное обеспечение способно

выполнять некоторые операции параллельно, поэтому в действительности длина

цикла зависит от количества

 последовательных

 операций в одном цикле.

Должен также учитываться объем выполняемого декодирования. Посмотрите

на рис. 4.5. Вспомните, что в АЛУ может передаваться значение одного из девяти
регистров, и чтобы определить, какой именно регистр нужно выбрать, требуется
всего 4 бита в микрокоманде. К сожалению, такая экономия дорого обходится.

Схема декодера вносит дополнительную задержку в работу компьютера. Это зна-

чит, что какой бы регистр мы не выбрали, он получит команду немного позже и

передаст свое содержимое на шину В немного позже. Следовательно, АЛУ полу-

чает входные сигналы и выдает результат также с небольшой задержкой. Соответ-
ственно, этот результат поступает на шину С для записи в один из регистров тоже

немного позже. Поскольку эта задержка часто является фактором, который опре-

деляет длину цикла, это значит, что генератор синхронизирующего сигнала не

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

правильный выбор. В компьютере с высокой производительностью использовать

декодер не рекомендуется, а вот для дешевой машины он вполне подойдет.

2 7 4

 Глава 4. Микроархитектурный уровень

Сокращение длины пути

Микроархитектура Mic-1 имеет относительно простую структуру и работает до-

вольно быстро, хотя эти две характеристики очень трудно совместить. В общем
случае простые машины не являются высокоскоростными, а высокоскоростные
машины довольно сложны. Процессор Mic-1 использует минимум аппаратного
обеспечения; 10 регистров, простое АЛУ (см. рис. 3.18), продублированное 32 раза,

декодер, схему сдвига, управляющую память и некоторые связующие элементы.

Для построения всей системы требуется менее 5000 транзисторов, управляющая
память (ПЗУ) и основная память (ОЗУ).

Мы уже показали, как можно воплотить IJVM с помощью микропрограммы,

используя небольшое количество аппаратного обеспечения. Теперь рассмотрим

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

Слияние цикла интерпретатора с микропрограммой

В микроархитектуре Mic-1 основной цикл состоит из микрокоманды, которая долж-

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

ее перекрытие предыдущей командой. В каком-то смысле эта идея уже получила

свое воплощение. Вспомните, что во время цикла Mainl код следующей операции
уже находится в регистре MBR. Этот код операции был вызван или во зремя пре-

дыдущего основного цикла (если у предыдущей команды не было операндов), или

во время выполнения предыдущей команды.

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

свести к нулю. Это происходит следующим образом. Рассмотрим каждую после-

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

одним и тем же набором целевых объектов). В некоторых случаях микрокоманда

Mic-1 может сливаться с предыдущими микрокомандами, поскольку эти команды

не всегда полностью используются.

В табл. 4.5 приведена последовательность микрокоманд для команды POP.

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

Таблица 4.5.

 Новая микропрограмма для выполнения команды POP

Микрокоманда Операции Комментарий

рор1 MAR=SP=SP-1; rd Считывание второго сверху слова в стеке
рор2 Ожидание, пока из памяти считается новое

значение TOS

рорЗ TOS=MDR; goto Mainl Копирование нового слова в регистр TOS

Mainl PC=PC+1; fetch; Регистр MBR содержит код операции; вызов

goto(MBR) следующего байта; переход

Разработка микроархитектурного уровня

  2 7 5

В табл. 4.6 последовательность сокращена до трех команд за счет того, что в

ц<ткле рор2 АЛУ не используется. Отметим, что в конце этой последовательности

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

щей микрокоманды на один цикл, поэтому, например, последующая команда IADD
сокращается с четырех циклов до трех. Это эквивалентно повышению частоты син-

хронизирующего сигнала с 250 МГц (каждая микрокоманда по 4 не) до 333 МГц

(каждая микрокоманда по 3 не).

Таблица 4.6.

 Усовершенствованная микропрограмма для выполнения команды POP

Микрокоманда Операции Комментарий

рор1 MAR>SP=SP-1; rd Считывание второго сверху слова

 в

 стеке

Maini pop PC=PC+1; fetch Регистр MBR содержит код операции, вызов

следующего байта

рорЗ TOS=MDR, goto(MBR) Копирование нового слова в регистр TOS; переход

к коду операции

Команда POP очень хорошо подходит для такой переработки, поскольку она со-

держит цикл, в котором АЛУ не используется, а основной цикл требует АЛ У. Таким

образом, чтобы сократить длину команды на одну микрокоманду, нужно в этой ко-

манде найти цикл, где АЛУ не используется. Такие циклы встречаются нечасто, но

все-таки встречаются, поэтому установка цикла Mai nl в конце каждой последователь-
ности микрокоманд вполне целесообразна. Для этого требуется всего лишь неболь-

шая управляющая память. Итак, мы получили первый способ сокращения длины пути:

помещение основного цикла в конце каждой последовательности микрокоманд.

Трехшинная архитектура

Что еще можно сделать, чтобы сократить длину пути? Можно подвести к АЛУ две
полные входные шины, А и В, и следовательно, всего получится три шины. Все (или,
по крайней мере, большинство регистров) должны иметь доступ к обеим входным
шинам. Преимущество такой системы состоит в том, что есть возможность склады-

вать любой регистр с любым другим регистром за один цикл. Чтобы увидеть, насколько
продуктивен такой подход, рассмотрим реализацию команды ILOAD (табл. 4 7).

Таблица 4.7.

 Микропрограмма для выполнения команды ILOAD

Микрокоманда Операции Комментарий

MBR содержит индекс, копирование LV в Н
MAR= адрес локальной переменной, которую нужно

поместить в стек

Регистр SP указывает на новую вершину стека,

подготовка к записи

Увеличение PC на 1, вызов следующего кода

операции, запись вершины стека
Обновление TOS
Регистр MBR содержит код операции; вызов
следующего байта, переход

iloadi
iload2

iload3

iload4

iload5

Mam1

H=LV
MAR=MBRU+H, rd

MAR=SP=SP+1

PC=PC+1; fetch; wr

TOS=MDR;gotoMain1

PC=PC+1; fetch;
goto(MBR)

2 7 6

 Глава 4. Микроархитектурный уровень

Мы видим, что в микрокоманде iloadl значение LV копируется в регистр Н.

Это нужно только для того, чтобы сложить Н с MBRU в микрокоманде iload2.
В разработке с двумя шинами нет возможности складывать два произвольных

регистра, поэтому один из них сначала нужно копировать в регистр Н. В трех-
шинной архитектуре мы можем сэкономить один цикл, как показано в табл. 4.8.

Мы добавили основной цикл к команде IL0AD, но при этом длина пути не увели-

чилась и не уменьшилась. Однако дополнительная шина сокращает общее время
выполнения команды с шести циклов до пяти циклов. Теперь мы знаем второй
способ сокращения длины пути:

переход от двухшинной к трехшинноп архитектуре.

Таблица 4.8.

 Микропрограмма для выполнения команды ILOAD при наличии

трехшинной архитектуры

Микрокоманда Операции Комментарий

MAR= адрес локальной переменной, которую нужно

поместить в стек
Регистр SP указывает на новую вершину стека;
подготовка к записи

Увеличение PC на 1; вызов следующего кода
операции; запись вершины стека
Обновление TOS

Регистр MBR уже содержит код операции; вызов

индексного байта

Блок выборки команд

Оба эти способа стоит использовать, но чтобы достичь существенного продвиже-

ния, требуется нечто более радикальное. Давайте вернемся чуть-чуть назад и рас-

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

1. Значение PC пропускается через АЛУ и увеличивается на 1.

2. PC используется для вызова следующего байта в потоке команд.
3. Операнды считываются из памяти.

4. Операнды записываются в память.

5. АЛУ выполняет вычисление, и результаты сохраняются в памяти.
Если команда содержит дополнительные поля (для операндов), каждое поле

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

ко после того, как эти байты будут объединены. При вызове и компоновке поля

АЛУ должно для каждого байта увеличивать PC на единицу, а затем объединять
получившийся индекс или смещение. Когда помимо выполнения основной рабо-
ты команды приходится вызывать и объединять поля этой команды, АЛУ исполь-

зуется практически в каждом цикле.

Чтобы объединить основной цикл с какой-нибудь микрокомандой, нужно

освободить АЛУ от некоторых таких задач. Для этого можно ввести второе АЛУ,
хотя работа полного АЛУ в большинстве случаев не потребуется. Отметим, что

Iloadl

Iload2

Iloacl3

!load4
lloadS

MAR=MBRU+LV; rd

MAR=SP=SP+1

PC=PC+1; fetch; wr

TOS=MDR

PC=PC+1; fetch;

goto(MBR)

АЛУ часто применяется для копирования значения из одного регистра в другой.
Эти циклы можно убрать, если ввести дополнительные тракты данных, которые

не проходят через АЛУ. Полезно будет, например, создать тракт от TOS к MDR

или от MDR к TOS, поскольку верхнее слово стека часто копируется из одного
регистра в другой.

В микроархитектуре Mic-1 с АЛУ можно снять большую часть нагрузки, если

создать независимый блок для вызова и обработки команд. Этот блок, который

называется

 блоком выборки команд,

 может независимо от АЛУ увеличивать зна-

чение PC на 1 и вызывать байты из потока байтов до того, как они понадобятся.
Этот блок содержит инкрементор, который по строению гораздо проще, чем пол-
ный сумматор. Разовьем эту идею. Блок выборки команд может также объединять
8-битные и 16-битные операнды, чтобы они могли использоваться сразу, как толь-
ко они стали нужны. Это можно осуществить, по крайней мере, двумя способами:

1. Блок выборки команд может интерпретировать каждый код операции, опре-

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

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

2. Блок выборки команд может постоянно предоставлять следующие 8- или

16-битные куски информации независимо от того, имеет это смысл или нет.

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

Рис. 4.18. Блок выборки команд для микроархитектуры Мю-1

На рис. 4.18 показан второй способ реализации. Вместо одного 8-разрядного

регистра MBR (буферного регистра памяти) здесь есть два регистра MBR: 8-раз-

рядныи MBR1 и 16-разрядный MBR2. Блок выборки команд следит за самым по-

следним байтом или байтами, которые поступили в основной операционный блок.