Обработчики прерываний и исключительных состояний

Архитектура памяти,

Взаимодействие с внешними устройствами ввода/ вывода,

Режимы адресации,

Регистры,

Машинные команды,

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

обработчики прерываний и исключительных состояний.

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

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

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

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

Но все это в теории. А теперь перейдем к суровой реальности. Когда появляется новая машина, первый вопрос, который задают все потенциальные покупатели: "Совместима ли машина с предыдущими версиями?" Второй вопрос: "Можно ли запустить на ней прежнюю операционную систему?" И третий вопрос: "Будут ли работать на этой машине прежние приложения и не потребуется ли заменять их новыми версиями?" Если ответ на любой из этих вопросов оказывается отрицательным, разработчики должны объяснить, почему. Покупатели вряд ли захотят выбросить свои любимые программы, чтобы начать все заново.

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

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

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

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

Систе́ма кома́нд (также набо́р команд) — соглашение о предоставляемых архитектурой средствах программирования, а именно: определённых типах данных, инструкций, системы регистров, методов адресации, моделей памяти, способов обработки прерываний и исключений, методов ввода и вывода.

Система команд представляется спецификацией соответствия (микро)команд наборам кодов (микро)операций, выполняемых при вызове команды, определяемых (микро)архитектурой системы. (При этом, на системах с различной (микро)архитектурой может быть реализована одна и та же система команд. Например, Intel Pentium и AMD Athlon имеют почти идентичные версии системы команд x86, но имеют радикально различный внутренний дизайн.)

Базовыми командами являются, как правило, следующие:

арифметические, например «сложения» и «вычитания»;

битовые, например «логическое и», «логическое или» и «логическое не»;

присваивание данных, например «переместить», «загрузить», «выгрузить»;

ввода-вывода, для обмена данными с внешними устройствами;

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

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

Если объединить наиболее часто используемую последовательность микроопераций под одной микрокомандой, то надо будет обеспечивать меньше микрокоманд. Такое построение системы команд носит название CISC (Complex Instruction Set Computer), в распоряжении имеется небольшое число составных команд.

С другой стороны, это объединение уменьшает гибкость системы команд. Вариант с наибольшей гибкостью — наличие множества близких к элементарным операциям команд. Это RISC (Reduced Instruction Set Computer), в распоряжении имеются усечённые, простые команды.

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

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

Модели памяти: Во всех компьютерах память разделена на ячейки, имеющие последовательные номера (адреса). В настоящее время наиболее распространенной ячейкой является байт. Байты обычно группируются в 2, 4 или 8 - байтные слова, которыми манипулируют команды. Многие архитектуры требуют, чтобы слова были выровнены на их целочисленную границу (быстродействие и экономичность). Например, 4-байтовое слово должно начинаться с адреса, кратного 4. Большинство современных машин имеют единое линейное адресное пространство, от 0 до некоторого максимума. Некоторые компьютеры поддерживают раздельные адресные пространства для команд и данных. Такая система гораздо сложнее, но имеет два преимущества. Во-первых, появляется возможность 32-битной адресации к 232 байтам для программы и такому же количеству данных. Во-вторых, из программы можно делать запись только в область данных, поэтому случайная перезапись программы становится невозможной. Это устраняет один из распространенных источников программных сбоев.

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

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

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

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

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

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

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

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

♦ N - результат отрицателен (Negative); + Z - результат равен 0 (Zero);

♦ V - результат вызвал переполнение (oVerflow);

♦ С - перенос самого левого бита (Carry out);

♦ А - перенос бита 3 (Auxiliary carry - служебный перенос);

♦ Р - результат четный (Parity).

Коды условий очень важны, поскольку используются при сравнениях и условных переходах. Например, команда СМР обычно вычитает один операнд из другого и на основе полученной разности устанавливает коды условий. Если операнды равны, то разность будет равна 0, а во флаговом регистре установится бит Z. Последующая команда BEQ (Branch Equal - переход в случае равенства) проверяет бит Z и совершает переход, если он установлен.

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

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

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

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

Теперь рассмотрим другую бухгалтерскую фирму, только что заключившую договор на проверку федерального долга (размера задолженности правительства США всем контрагентам). 32-разрядная арифметика здесь не подойдет, поскольку числа превышают значение 232 (около четырех миллиардов). Одно из возможных решений - использовать два 32-разрядных целых числа для представления каждого числа, то есть все 64 бита. Если машина не поддерживает такие числа удвоенной точности, все арифметические операции над ними должны выполняться программно, то есть эти две части могут располагаться в памяти в произвольном порядке, поскольку для аппаратного обеспечения это не важно. Это - пример типа данных без аппаратной поддержки и, следовательно, без аппаратной реализации. В следующих подразделах мы рассмотрим типы данных, которые поддерживаются аппаратно и для которых требуются специальные форматы.

Поиск по сайту: