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

В предыдущем подразделе мы увидели, что короткие адреса препятствуют удачной дискретности памяти. В этом разделе мы рассмотрим компромиссы, связанные с кодами операций и адресами. Рассмотрим команду размером п + k бит с кодом операции в k бит и одним адресом в п бит. Такая команда допускает 2^k различных операций и 2^п адресуемых ячеек памяти. В качестве альтернативы те же п + k бит можно разбить на код операции в k – 1 бит и адрес в /2+1 бит. При этом будет либо в два раза меньше команд, но в два раза больше памяти, либо то же количество памяти, но дискретность вдвое выше. Код операции в k + 1 бит и адрес в п – 1 бит дает большее количество операций, но ценой этого является либо меньшее количество ячеек памяти, либо не очень удачная дискретность при том же объеме памяти. Наряду с подобными простыми компромиссами между битами кода операции и битами адреса существуют и более сложные. Обсуждаемый здесь механизм называется расширением кода операций.

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

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

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

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

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

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

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