Архитектура компьютера

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

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

Эффективность конкретной архитектуры команд зависит от технологии, которая применялась при разработке компьютера. За длительный период времени эта технология значительно изменится, и некоторые характеристики архитектуры команд окажутся (если оглянуться лет на 20 назад) неудачными. Например, если доступ к памяти осуществляется быстро, то подойдет стековая архитектура (как в IJVM), но если доступ к памяти медленный, тогда желательно иметь множество регистров (как в UltraSPARC III). Тем читателям, которые считают, что выбор сделать просто, мы предлагаем взять лист бумаги и записать следующие предположения:
Читать дальше »

А теперь посмотрим, какое отношение язык Java имеет к IJVM. В листинге 4.1 представлен небольшой фрагмент программы на языке Java. Компилятор Java должен был бы переделать эту программу в программу на языке ассемблера IJVM, приведенную в листинге 4.2. Цифры с 1 по 15 в левой части листинга, а также комментарии после символов двойной косой черты (//) не являются частью самой программы. Они даны для наглядности и просто облегчают понимание. Затем ассемблер Java транслировал бы ее в программу в двоичном коде. Эта программа представлена в листинге 4.3. (В действительности результатом работы компилятора Java сразу является двоичный код.) В данном примере i — локальная переменная 1, j — локальная переменная 2, а к — локальная переменная 3.

Скомпилированная программа проста. Сначала j и к помещаются в стек, складываются, а результат сохраняется в i. Затем i и константа 3 помещаются в стек и сравниваются. Если они равны, то совершается условный переход к L1, где к получает значение 0. Если они не равны, то выполняется часть программы после команды IF_ICMPEQ. После этого осуществляется переход к L2, где объединяются части else и then.
Читать дальше »

Набор IJVM-команд приведен в табл. 4.2. Каждая команда состоит из кода операции и иногда из операнда (например, смещения адреса или константы). В первом столбце приводится шестнадцатеричный код команды. Во втором столбце дается мнемоника на языке ассемблера. В третьем столбце описывается назначение команды.

Команды нужны для того, чтобы помещать слова из различных источников в стек. Источники — это набор констант (LDC_W), фрейм локальных переменных (IL0AD) и сама команда (BIPUSH). Переменную можно также вытолкнуть из стека и сохранить во фрейме локальных переменных (ISTORE). Над двумя верхними словами стека можно совершать две арифметические (IADD и ISUB) и две логические операции (IAND и I0R). При выполнении любой арифметической или логической операции два слова выталкиваются из стека, а результат помещается обратно в стек. Существует 4 команды перехода: одна для безусловного перехода (GOTO), а три другие для условных переходов (IFEQ, IFLT и IFICMPEQ). Все эти команды изменяют значение PC на размер их смещения, который следует за кодом операции в команде. Операнд смещения состоит из 16 бит. Он прибавляется к адресу кода операции. Существуют также команды для перестановки двух верхних слов стека (SWAP), дублирования верхнего слова (DUP) и удаления верхнего слова (POP).
Читать дальше »

А теперь мы можем рассмотреть архитектуру IJVM. Она состоит из памяти, которую можно рассматривать либо как массив из 4 294 967 296 байт (4 Гбайт), либо как массив из 1 073 741 824 слов, каждое из которых содержит 4 байта. В отличие от большинства архитектур команд, виртуальная машина Java не выполняет обращений к памяти, видимых на уровне команд, но имеет несколько неявных адресов, которые составляют основу указателя. IJVM-команды могут обращаться к памяти только через эти указатели. Определены следующие области памяти:

? Набор констант. Эта область, недоступная для записи из IJVM-програм-мы, состоит из констант, строк и указателей на другие области памяти, на которые можно делать ссылку. Данная область загружается в момент загрузки программы в память и после этого не меняется. Имеется скрытый регистр СРР (Constant Pool Pointer — указатель набора констант), который содержит адрес первого слова набора констант.

? Фрейм локальных переменных. Эта область предназначена для хранения переменных во время выполнения процедуры. Она, как уже отмечалось, называется фреймом локальных переменных. В начале этого фрейма располагаются параметры (или аргументы) вызванной процедуры. Фрейм локальных переменных не включает в себя стек операндов. Он помещается отдельно. Исходя из соображений производительности, мы поместили стек операндов прямо над фреймом локальных переменных. Существует скрытый регистр, который содержит адрес первой переменной фрейма. Мы назовем этот регистр LV (Local Variable — локальная переменная). Параметры вызванной процедуры хранятся в начале фрейма локальных переменных.
Читать дальше »

Во всех языках программирования есть понятие процедур (методов), имеющих локальные переменные. Эти переменные доступны во время выполнения процедуры, но перестают быть доступными после ее окончания. Возникает вопрос: где должны храниться такие переменные?

К сожалению, предоставить каждой переменной абсолютный адрес в памяти невозможно. Проблема заключается в том, что процедура может вызывать себя сама. Мы рассмотрим такие рекурсивные процедуры в главе 5. А пока достаточно сказать, что если процедура вызывается дважды, то хранить ее переменные под конкретными адресами в памяти нельзя, поскольку второй вызов перемешается с первым.
Читать дальше »

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

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

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

Тракт данных — это часть центрального процессора, состоящая из АЛУ (арифметико-логического устройства), его входов и выходов. Тракт данных нашей микроархитектуры показан на рис. 4.1. Хотя этот тракт данных и был оптимизирован для интерпретации IJVM-программ, он схож с трактами данных большинства компьютеров. Тракт содержит ряд 32-разрядных регистров, которым мы приписали символические названия (например, PC, SP, MDR). Хотя некоторые из этих названий нам знакомы, важно понимать, что эти регистры доступны только на уровне микроархитектуры (для микропрограммы). Им даны такие названия, поскольку они обычно содержат значения, соответствующие переменным с аналогичными названиями на уровне архитектуры команд. Содержание большинства регистров передается на шину В. Выходной сигнал АЛУ управляет схемой сдвига и далее шиной С. Значение с шины С может записываться в один или несколько регистров одновременно. Шину А мы введем позже, а пока представим, что ее нет.
Читать дальше »

В идеале неплохо было бы сначала описать общие принципы разработки уровня микроархитектуры, но, к сожалению, таких общих принципов не существует. Каждая разработка индивидуальна. По этой причине мы просто подробно рассмотрим конкретный пример. В качестве примера мы выбрали подмножество виртуальной машины Java. Это подмножество содержит только целочисленные команды, поэтому мы назвали его IJVM (Integer Java Virtual Machine — виртуальная машина Java для целых). Виртуальную машину в целом (JVM) мы рассмотрим в главе 5.

Начнем мы с описания микроархитектуры, на базе которой воплотим IJVM. IJVM содержит несколько довольно сложных команд. Как уже отмечалось в главе 1, подобные архитектуры часто реализуются путем микропрограммирования. Хотя структура IJVM не слишком сложная, она может стать хорошей отправной точкой при описании основных принципов обработки команд и последовательности их выполнения.
Читать дальше »