Э. Таненбаум - Архитектура компьютера (1127755), страница 93
Текст из файла (страница 93)
Кроме того, из чисто практических соображений компьютеры должны уметь выполнять программы, написанные на разных языках, а не только на одном. В сущности, все разработчики считают, что нужно транслировать программы, написанные на различных языках высокого уровня, в некую общую для всех промежуточную форму — уровень архитектуры набора команд — и, соответственно, строить аппаратное обеспечение, которое сможет непосредственно выполнять программы этого уровня. Уровень архитектуры набора команд связывает компиляторы и аппаратное обеспечение.
Это язык, который понятен и компиляторам, и устройствам. На рис. 5.1 показана взаимосвязь компиляторов, уровня архитектуры набора команд н аппаратного обеспечения. 374 Глава 5. Уровень архитектуры набора команд В идеале при создании новой машины разработчики архитектуры команд должны консультироваться с разработчиками и компиляторов, и аппаратуры, чтобы выяснить, какими особенностями должен обладать подведомственный им уровень. Если разработчики компилятора потребуют какого-то свойства, которое инженеры не смогут реализовать, то такая идея не пройдет.
Точно так же, если разработчики аппаратного обеспечения захотят ввести в компьютер какой-либо новый элемент, но программисты не смогут написать поддерживающую его программу, такой проект никогда не воплотится. Реализуемый в конечном итоге уровень архитектуры набора команд, оптимизированный для нужных языков программирования, всегда является плодом долгих обсуждений и моделирования. Но все это в теории. А теперь перейдем к суровой реальности.
Когда появляется новая машина, первый вопрос, который задают все потенциальные покупатели: «Совместима ли машина с предыдущими версиями?» Второй вопрос: «Можно ли запустить на ней прежнюю операционную систему?» И третий вопрос «Будут ли работать на этой машине прежние приложения и не потребуется ли заменять их новыми версиями?» Если ответ на любой из этих вопросов оказывается отрицательным, разработчики должны объяснить, почему. Покупатели вряд ли захотят выбросить свои любимые программы, чтобы начать все заново. Этот факт заставляет производителей компьютеров поддерживать один и тот же уровень команд в разных моделях или, по крайней мере, делать его обратно совместимым.
Под обратной совместимостью мы понимаем способность новой машины выполнять старые программы без изменений. В то же время новая машина может поддерживать новые команды и иметь другие особенности, используемые новым программным обеспечением. Разработчики должны делать уровень команд совместимым с предыдущими моделями, но они вправе как угодно менять аппаратное обеспечение, поскольку едва ли кого-нибудь из покупателей волнует, что собой в реальности представляют «внутренности» компьютера и что именно делает то или иное устройство.
Разработчики могут переходить от микропрограмм к непосредственному использованию устройств, добавлять конвейеры, реализовывать суперскалярные схемы и т. п., но при условии, что они сохранят обратную совместимость с уровнем команд предыдущих моделей. Основная цель — убедиться, что старые программы работают на новой машине.
То есть на первый план выходит задача не просто создания хороших машин, а создания хороших машин при условии их обратной совместимости. Все сказанное вовсе не принижает значимость уровня архитектуры набора команд. Качественный уровень архитектуры набора команд чрезвычайно важен, особенно в отношении вычислительных возможностей и стоимости.
Производительность эквивалентных машин с разными уровнями архитектуры набора команд может различаться на 25 Ж. Мы просто хотим сказать, что рынок в определенной степени затрудняет переход от старой архитектуры команд к новой. Тем не менее иногда появляются новые уровни команд универсального назначения, а на специализированных рынках (например, на рынке встроенных систем или на рынке мультимедийных процессоров) они возникают гораздо чаще.
Следовательно, важно понимать принципы работы этого уровня. Общий обзор уровня архитектуры набора команд 375 Какую архитектуру команд можно считать хорошейте Существуют два основных фактора. Во-первых, хорошая архитектура должна предлагать набор команд, которые можно эффективно реализовать не только в современной, но и в будущей технике. При плохо разработанной архитектуре команд процессор может строиться из большего числа вентилей, для выполнения программ может требоваться больший объем памяти и т. д.
Проект, в котором должным образом учтены особенности конкретной техники, может стать основой для производства целого поколения компьютеров, прийти на смену которым сможет система с еще более совершенной архитектурой команд. Во-вторых, хорошая архитектура команд должна обеспечивать предельную ясность в отношении того, какой именно должна быть откомпилированная программа. Регулярность и полнота вариантов — те черты, которые не всегда свойственны архитектуре команд.
Эти черты особенно важны для компилятора, который не всегда может сделать оптимальный выбор из нескольких альтернатив, особенно если некоторые очевидные на первый взгляд альтернативы архитектурой команд не поддерживаются. Если говорить кратко, поскольку уровень архитектуры набора команд является промежуточным звеном между аппаратным и программным обеспечением, он должен быть приемлемым и для разработчиков аппаратного обеспечения (с точки зрения эффективной реализации), и для программистов (с точки зрения написания качественного кода).
Общий обзор уровня архитектуры набора команд Давайте начнем изучение уровня архитектуры набора команд с вопроса о том, что он собой представляет. Этот вопрос на первый взгляд может показаться простым, но на самом деле здесь очень много тонкостей. В следующем подразделе мы обсудим некоторые из них, а затем мы рассмотрим модели памяти, регистров и команд. Свойства уровня архитектуры набора команд В принципе уровень архитектуры набора команд — это тот уровень, на котором компьютер представляется программисту, пишущему программы на машинном языке.
Поскольку сейчас ни один нормальный программист таких программ не пишет, мы слегка переделали зто определение: программа уровня архитектуры набора команд — это то, что получается в результате работы компилятора (в данный момент мы будем касаться системных вызовов и символического языка ассемблера). Чтобы получить программу уровня архитектуры набора команд, создатель компилятора должен знать, какая модель памяти используется в машине, какие регистры, типы данных и команды имеются в наличии, и т.
д. Вся эта информация в совокупности и определяет уровень архитектуры набора команд. В соответствии с этим определением вопросы о том, доступна ли микроархитектура программно, конвейеризирован ли компьютер, является ли он суперскалярным и т. д., не относятся к уровню архитектуры набора команд, поскольку 376 Глава 5. Уровень архитектуры набора команд разработчик компилятора всего этого не видит. Однако это замечание не совсем справедливо, поскольку некоторые из этих характеристик влияют на производительность, а производительность, в свою очередь, — вполне доступный для разработчика компилятора показатель.
Рассмотрим, например, суперскалярную машину, которая в одном цикле может обрабатывать сдвоенные команды, причем такие, что одна команда целочисленная, а вторая с плавающей точкой. Если в коде, полученном в результате работы компилятора, целочисленные команды и команды с плавающей точкой будут чередоваться, то производительность заметно повысится. Таким образом, детали суперскалярной операции доступны на уровне архитектуры набора команд, то есть границы между разными уровнями размыты. Для одних архитектур уровень команд определяется формальным документом, который обычно выпускается промышленным консорциумом, для других— нет.
Например, системы к'9 БРАКС (Четв|оп 9 БРАКС) и )УМ имеют официальные определения ~216). Цель такого официального документа — дать возможность различным производителям выпускать машины данного типа, чтобы эти машины могли выполнять одни и те же программы и получать при этом одни и те же результаты. В случае с системой БРАКС подобные документы нужны для того, чтобы различные предприятия могли выпускать идентичные микросхемы БРАКС, отличающиеся друг от друга только по производительности и цене. Чтобы эта идея работала, поставщики микросхем должны знать, что делает микросхема БРАКС (на уровне архитектуры набора команд). Следовательно, в документе говорится о том, какова модель памяти, какие имеются регистры, какие действия выполняют команды и т.
д., а не о том, что представляет собой микроархитектура. В таких документах содержатся нормативные разделы, в которых излагаются требования, и информативные разделы, призванные помочь читателю, но не являющиеся частью формального определения. В нормативных разделах постоянно встречаются такие слова, как должно быть, нельзя, следует, означающие, соответственно, требование, запрет и рекомендацию. Например, следующее предложение означает, что если программа выполняет код операции, который не определен, он должен вызывать системное прерывание, а не просто игнорироваться: Выполнение зарезервированного кода операции должно вызывать системное прерывание.
Может быть и альтернативный подход: Результат выполнения зарезервированного кода операции определяется реализацией. Это значит, что составитель компилятора не может просчитать какие-то конкретные действия предоставляет конструкторам свободу выбора. К описанию архитектуры часто прилагаются тестовые пакеты для проверки, действительно ли данная реализация соответствует техническим требованиям.
Совершенно ясно, почему система Ч9 БРАКС поставляется с документом, в котором определяется уровень архитектуры набора команд, — это нужно для того, чтобы все микросхемы У9 БРАКС могли выполнять одни и те же програм- Общий обзор уровня архитектуры набора команд 3 г7 мы. Для уровня архитектуры набора команд процессора Репйпш 4 такого документа нет, поскольку компания 1пге1 не хочет, чтобы другие производители могли выпускать микросхемы Репгшш 4. Компания 1псе! даже обращалась в суд, чтобы запретить производство своих микросхем другим производителям, но проиграла процесс. Другое важное качество уровня архитектуры набора команд состоит в том, что в большинстве машин поддерживаются по крайней мере два режима.
В привилегированном режиме запускается операционная система. Этот режим позволяет выполнять все команды. Пользовательский режим предназначен для запуска прикладных программ. Он не позволяет выполнять некоторые потенциально опасные команды (например, те, которые непосредственно манипулируют кэш-памятью). В этой главе мы в первую очередь сосредоточимся на командах и свойствах пользовательского режима. Модели памяти Во всех компьютерах память разделена на ячейки, которые имеют последовательные адреса.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
