Файл: Tannenbaum.pdf

Вопросы и задания 333

27. В конце раздела «Кэш-память» мы сказали, что заполнение по записи вы-

годно только в том случае, если имеют место повторные записи в одну и ту
же строку кэш-памяти. А если после записи следуют многочисленные счи-

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

большим преимуществом?

28. В черновом варианте этой книги на рис. 4.27 вместо 4-входовой ассоциатив-

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

Один из рецензентов заявил, что читателей это может сильно смутить, по-

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

вую ассоциативную кэш-память. Был ли рецензент прав? Аргументируйте.

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

дов простаивает следующие три цикла. Насколько эти простаивания снизят
производительность, если 20% команд являются условными переходами?
Другие причины простаиваний не учитывайте.

30. Предположим, что компьютер вызывает до 20 команд заранее. В среднем 4 из

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

ного прогнозирования каждого из этих условных переходов равно 90%. Како-
ва вероятность, что предварительный вызов команд на правильном пути?

31. Предположим, что нам пришлось изменить структуру машины, показанную

в табл. 4.12, чтобы использовать 16 регистров вместо 8. Тогда мы изменим

команду 6, чтобы использовать регистр R8 в качестве ее выходного регист-
ра. Что в этом случае будет происходить в циклах, начиная с цикла 6?

32. Обычно взаимозависимости затрудняют работу конвейеризированных про-

цессоров. Можно ли что-нибудь сделать с WAW-взаимозависимостью, что-
бы улучшить положение вещей? Какие существуют средства оптимизации?

33 Перепишите интерпретатор Mic-1 таким образом, чтобы регистр LV указы-

вал на первую локальную переменную, а не на связующий указатель.

34. Напишите моделирующую программу для одновходовой кэш-памяти пря-

мого отображения. Сделайте число элементов и длину строки параметрами

программы. Поэкспериментируйте с этой программой и изложите получен-
ные данные.

Глава 5

Уровень архитектуры команд

В этой главе подробно обсуждается уровень архитектуры команд. Он расположен

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

вают «архитектурой» машины, а иногда (что неправильно) «языком ассемблера»

Уровень архитектуры команд имеет особое значение: он является связующим

звеном между программным и аппаратным обеспечением. Конечно, можно было
бы сделать так, чтобы аппаратное обеспечение сразу непосредственно выполняло
программы, написанные на С, C++, FORTRAN 90 или других языках высокого
уровня, но это не очень хорошая идея. Преимущество компиляции перед интер-
претацией было бы тогда потеряно. Кроме того, из чисто практических соображе-
ний компьютеры должны уметь выполнять программы, написанные на разных язы-
ках, а не только на одном.

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

написанные на различных языках высокого уровня, в общую промежуточную фор-
му — на уровень архитектуры команд — и соответственно конструировать аппа-
ратное обеспечение, которое может непосредственно выполнять программы этого

уровня (уровня архитектуры команд). Уровень архитектуры команд связывает

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

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

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

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

Но все это в теории. А теперь перейдем к суровой реальности Когда появляет-

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

«Совместима ли машина с предыдущими версиями?». Второй вопрос: «Могу ли я

Уровень архитектуры команд

335

запустить на ней мою старую операционную систему?» И третий вопрос: «Будут
ли работать мои прикладные программы на этой машине и не потребуется ли их

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

Программа на языке

FORTRAN 90

Программа

на языке С

Программа на языке

FORTRAN 90,

скомпилированная

в машинные команды

Программа на языке С,

скомпилированная

в машинные команды

Уровень архитектуры команд

Программное

обеспечение

Программа из машинных команд

выполняется микропрограммой

или аппаратным обеспечением

Аппаратное

обеспечение

Аппаратное обеспечение

Рис.  5 . 1 . Уровень команд — это промежуточное звено между компиляторами

и аппаратным обеспечением

Этот факт заставляет компьютерных разработчиков сохранять один и тот же

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

 обратно со-

вместимым.

 Под обратной совместимостью мы понимаем способность новой ма-

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

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

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

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

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

новой машине. Тогда возникает проблема

1

 построение лучших машин, но с обрат-

ной совместимостью.

Все это вовсе не значит, что разработка уровня команд не имеет никакого зна-

чения. Хорошо разработанный уровень архитектуры команд имеет огромные пре-

имущества перед плохим, особенно в отношении вычислительных возможностей

и стоимости Производительность эквивалентных машин с различными уровнями

команд может различаться на 25%. Мы просто хотим сказать, что рынок несколько
затрудняет (хотя и не делает невозможным) устранение старой архитектуры ко-

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

гораздо чаще. Следовательно, важно понимать принципы разработки этого уровня.

336 Глава 5 Уровень архитектуры команд

Какую архитектуру команд можно считать хорошей? Существует два основ-

ных фактора. Во-первых, хорошая архитектура должна определять набор команд,

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

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

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

требоваться большее количество вентилей для процессора и больший объем памя-

ти для выполнения программ. Кроме того, машина может работать медленнее,

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

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

конкретной техники, может повлечь за собой производство целого поколения

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

архитектура команд.

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

оттранслированной программы. Регулярность и полнота вариантов — важные чер-

ты, которые не всегда свойственны архитектуре команд. Эти качества важны для

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

особенно когда некоторые очевидные на первый взгляд варианты не разрешены

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

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

лей программного обеспечения.

Общий обзор уровня архитектуры команд

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

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

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

Свойства уровня команд

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

шет программ на машинном языке, мы переделали это определение. Программа
уровня архитектуры команд — это то, что выдает компилятор (в данный момент

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

В соответствии с этим определением такие вопросы, как программируется ли

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

Общий обзор уровня архитектуры команд 337

совсем справедливо, поскольку некоторые из этих свойств влияют на производи-
тельность, а производительность является видимой для программиста. Рассмот-
рим, например, суиерскалярную машину, которая может выдавать back-to-back

команды в одном цикле, при условии что одна команда целочисленная, а одна —

с плавающей точкой. Если компилятор чередует целочисленные команды и коман-

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

различными уровнями размыты.

Для одних архитектур уровень команд определяется формальным документом,

который обычно выпускается промышленным консорциумом, для других — нет.

Например, V9 SPARC (Version 9 SPARC) и JVM имеют официальные определе-
ния [156, 85]. Цель такого официального документа — дать возможность различ-

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

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

личные предприятия могли выпускать идентичные микросхемы SPARC, отлича-

ющиеся друг от друга только производительностью и ценой. Чтобы эта идея работа-

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

представляет собой микроархитектура.

В таких документах содержатся нормативные разделы, в которых излагаются

требования, и информативные разделы, которые предназначены для того, чтобы
помочь читателю, но не являются частью формального определения. В норматив-
ных разделах описаны требования и запреты. Например, такое высказывание, как:

выполнение зарезервированного кода операции должно вызывать системное пре-

рывание

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

то он должен вызывать системное прерывание, а не просто игнорироваться. Может
быть и альтернативный подход:

результат выполнения зарезервированного кода операции определяется реали-

зацией.

Это значит, что составитель компилятора не может просчитать какие-то конк-

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

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

Совершенно ясно, почему V9 SPARC имеет документ, в котором определяется

уровень команд: это нужно для того, чтобы все микросхемы V9 SPARC могли вы-

полнять одни и те же программы. По той же причине существует специальный

документ для JVM: чтобы интерпретаторы (или такие микросхемы, как picojava II)

могли выполнять любую допустимую программу JVM. Для уровня команд про-
цессора Pentium II такого документа нет, поскольку компания Intel не хочет, что-
бы другие производители смогли запускать микросхемы Pentium II. Компания Intel

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

предприятиями.