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

Архитектура SPARC была впервые введена в 1987 году компанией Sun Microsystems. Эта архитектура стала одной из первых RISC-архитектур промышленного назначения. Она была основана на исследовании, проведенном в Беркли в 80-е годы [161, 164]. Изначально архитектура SPARC была 32-разрядной, но UltraSPARC III — это 64-разрядная машина, основанная на архитектуре Version 9 SPARC, и именно ее мы будем описывать в этой главе. В целях согласованности с остальными частями книги мы будем называть данную систему UltraSPARC III, хотя на уровне архитектуры набора команд все машины UltraSPARC идентичны.

Структура памяти машины UltraSPARC III очень проста — линейный массив размером 2⁶⁴ байт. В настоящее время реализовать ее невозможно, поскольку память слишком велика (18 446 744 073 709 551 616 байт). Современные реализации имеют ограничение на размер адресного пространства, к которому они могут обращаться (2⁴⁴ байт у UltraSPARC III), но в будущем это число увеличится. Байты нумеруются слева направо, но можно перейти на нумерацию справа налево, установив один из битов во флаговом регистре.
Читать дальше »

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

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