Structured Computer Organization (Архитектура компьютера) / computer_organization_2003

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 показана взаимосвязь компиляторов, уровня архитектуры команд и аппаратного обеспечения.

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

Но все это в теории. А теперь перейдем к суровой реальности Когда появляется новая машина, первый вопрос, который задают все потенциальные покупатели «Совместима ли машина с предыдущими версиями?». Второй вопрос: «Могу ли я

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

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

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

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

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

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

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

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

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

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

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

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

совсем справедливо, поскольку некоторые из этих свойств влияют на производительность, а производительность является видимой для программиста. Рассмотрим, например, суиерскалярную машину, которая может выдавать 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 даже обращалась в суд, чтобы запретить производство своих микросхем другими предприятиями.

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

Модели памяти

Во всех компьютерах память разделена на ячейки, которые имеют последовательные адреса. В настоящее время наиболее распространенный размер ячейки — 8 битов, но раньше использовались ячейки от 1 до 60 битов (см. табл. 2.1). Ячейка из 8 битов называется байтом. Причина применения именно 8-битных байтов такова: символы ASCII кода занимают 7 битов, поэтому один символ ASCII плюс бит четности как раз подходит под размер байта. Если в будущем будет доминировать UNICODE, то ячейки памяти, возможно, будут 16-битными. Вообще говоря, число 24 лучше, чем 23, поскольку 4 — степень двойки, а 3 — нет.

Байты обычно группируются в 4-байтные (32-битные) или 8-байтные (64-бит- ные) слова с командами для манипулирования целыми словами. Многие архитектуры требуют, чтобы слова были выровнены в своих естественных границах. Так, например, 4-байтное слово может начинаться с адреса 0,4,8 и т. д., но не с адреса

1или 2. Точно так же слово из 8 байтов может начинаться с адреса 0,8 или 16, но не

садреса 4 или 6. Расположение 8-байтных слов показано на рис. 5.2.

Адрес

8 байтов

24

16

15 14 13 12 11 10 9 8 V8

Выровненное 8-байтовое слово в ячейке с адресом 8

Невыровненное 8-байтовое слово в ячейке с адресом 12

Рис. 5.2. Расположение слова из 8 байтов в памяти: выровненное (а); невыровненное (б). Некоторые машины требуют, чтобы слова в памяти были выровнены

Выравнивание адресов требуется довольно часто, поскольку при этом память работает более эффективно. Например, Pentium II, который вызывает из памяти по 8 байтов за раз, использует 36-битные физические адреса, но содержит только 33 адресных бита, как показано на рис. 3.41. Следовательно, Pentium II даже не сможет обратиться к невыровненной памяти, поскольку младшие три бита не определены явным образом. Эти биты всегда равны 0, и все адреса памяти кратны 8 байтам.

Тем не менее требование выравнивания адресов иногда вызывает некоторые проблемы. В процессоре Pentium II программы могут обращаться к словам, начиная с любого адреса, — это качество восходит к модели 8088 с шиной данных шириной в 1 байт, в которой не было такого требования, чтобы ячейки располагались в 8-байтных границах. Если программа в процессоре Pentium II считывает 4-байт- ное слово из адреса 7, аппаратное обеспечение должно сделать одно обращение к памяти, чтобы вызвать байты с 0-го по 7-й, и второе обращение к памяти, чтобы вызвать байты с 8-го по 15-й. Затем центральный процессор должен извлечь требуемые 4 байта из 16 байтов, считанных из памяти, и скомпоновать их в нужном порядке, чтобы сформировать 4-байтное слово.

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

Большинство машин имеют единое линейное адресное пространство, которое простирается от адреса 0 до какого-то максимума, обычно 232 байтов или 2е4 байтов.

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

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

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

Еще один аспект модели памяти — семантика памяти. Естественно ожидать, что команда LOAD, которая встречается после команды STORE и которая обращается к тому же адресу, возвратит только что сохраненное значение. Тем не менее, как мы видели в главе 4, во многих машинах микрокоманды переупорядочиваются.

3 4 0 Глава 5. Уровень архитектуры команд

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

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

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

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

Регистры

Во всех компьютерах имеется несколько регистров, которые видны на уровне команд. Они нужны там для того, чтобы контролировать выполнение программы, хранить временные результаты, а также для некоторых других целей. Обычно регистры, которые видны на микроархитектурном уровне, например TOS и MAR (см. рис. 4.1), не видны на уровне команд. Тем не менее некоторые из них, например счетчик команд и указатель стека, присутствуют на обоих уровнях. Регистры, которые видны на уровне команд, всегда видны на микроархитектурном уровне, поскольку именно там они реализуются.

Регистры уровня команд можно разделить на две категории: специальные регистры и регистры общего назначения. Специальные регистры включают счетчик команд и указатель стека, а также другие регистры с особой функцией. Регистры общего назначения содержат ключевые локальные переменные и промежуточные результаты вычислений. Их основная функция состоит в том, чтобы обеспечить быстрый доступ к часто используемым данным (обычно избегая обращений к памяти). Машины RISC с высокоскоростными процессорами и медленной (относительно медленной) памятью обычно содержат как минимум 32 регистра общего назначения, а в новых процессорах количество этих регистров постоянно растет.

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

Вдругих машинах некоторые регистры общего назначения могут быть специализированы. Например, в процессоре Pentium II существует регистр EDX, который может использоваться в качестве регистра общего назначения, но который также получает половину произведения и содержит половину делимого при делении.

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

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

Есть один регистр управления, который представляет собой привилегирован- но-пользовательский гибрид. Это флаговый регистр, или PSW (Program State Word — слово состояния программы. Этот регистр содержит различные биты, которые нужны центральному процессору. Самые важные биты — это коды условия. Они устанавливаются в каждом цикле АЛ У и отражают состояние результата предыдущей операции. Биты кода условия включают:

•N — устанавливается, если результат был отрицательным (Negative);

•Z — устанавливается, если результат был равен 0 (Zero);

•V — устанавливается, если результат вызвал переполнение (oVerflow);

•С — устанавливается, если результат вызвал выход переноса самого левого бита (Carry out);

•А — устанавливается, если произошел выход переноса бита 3 (Auxiliary carry — служебный перенос);

•Р — устанавливается, если результат четный (Parity).

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

3 4 2 Глава 5. Уровень архитектуры команд

операнды равны, то разность будет равна 0 и во флаговом регистре будет установлен бит Z. Последующая команда BEQ (Branch Equal — переход в случае равенства) проверяет бит Z и совершает переход, если он установлен.

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

Команды

Главная особенность уровня, который мы сейчас рассматриваем, — это набор машинных команд. Они управляют действиями машины. В этом наборе всегда присутствуют команды LOAD и STORE (в той или иной форме) для перемещения данных между памятью и регистрами и команда MOVE для копирования данных из одного регистра в другой. Всегда присутствуют арифметические и логические команды и команды для сравнения элементов данных и переходов в зависимости от результатов. Некоторые типичные команды мы уже рассматривали (см. табл. 4.2.). А в этой главе мы рассмотрим многие другие команды.

Общий обзор уровня команд машины Pentium II

В этой главе мы обсудим три совершенно разные архитектуры команд: IA-32 компании Intel (она реализована в Pentium II), Version 9 SPARC (она реализована в процессорах SPARC) и JVM (она реализована в picojavall). Мы не преследуем цель дать исчерпывающее описание каждой из этих архитектур. Мы просто хотим продемонстрировать важные аспекты архитектуры команд и показать, как эти аспекты меняются от одной архитектуры к другой. Начнем с машины Pentium II.

Процессор Pentium II развивался на протяжении многих лет. Его история восходит к самым первым микропроцессорам, как мы говорили в главе 1. Основная архитектура команд обеспечивает выполнение программ, написанных для процессоров 8086 и 8088 (которые имеют одну и ту же архитектуру команд), а в машине даже содержатся элементы 8080 — 8-разрядный процессор, который был популярен в 70-е годы. На процессор 8080, в свою очередь, сильно повлияли требования совместимости с процессором 8008, который был основан на процессоре 4004 (4-битной микросхеме, применявшейся еще в каменном веке).

С точки зрения программного обеспечения, компьютеры 8086 и 8088 были 16-разрядными машинами (хотя компьютер 8088 содержал 8-битную шину данных). Их последователь 80286 также был 16-разрядным. Его главным преимуществом был больший объем адресного пространства, хотя небольшое число программ использовали его, поскольку оно состояло из 16 384 64 К сегментов, а не представляло собой линейную 224-байтную память.