Кагиров Р.Р. Лекции по Организации ЭВМ

Подождите немного. Документ загружается.

64 Гбайт оперативной памяти и выделять ее разным приложениям.

Условия вроде "не более двух гигов для чипсета такого-то" - это

ограничения именно чипсета, не умеющего обслуживать большой

объем памяти, а не 32-разрядной системы. Поэтому в серверных

приложениях, когда на одном сервере, как правило, запущено

несколько десятков одновременно работающих приложений,

пресловутый "барьер в 4 Гбайт" практически не ощущается. Но

означает ли это, что сегодня 64-разрядный x86 никому не нужен?

Конечно, нет! 64-разрядность виртуальной памяти в приложениях

востребована уже сейчас, просто эти "добавочные биты"

используются другими способами.

Во-первых, какую-то часть виртуального адресного пространства

может забирать операционная система. К примеру, MS Windows

обычно использует для своих нужд старший бит виртуального адреса,

ограничивая адресное пространство запущенного в ней приложения

31 битом и 2 Гбайт адресного пространства. А два гигабайта

оперативной памяти, согласитесь, куда ближе к реальной жизни,

нежели гипотетические четыре; и ситуацию, когда их начнет не

хватать, представить гораздо проще. Можно, правда, попытаться

использовать специальный режим, когда Windows будет

предоставлять процессам не два, а три гига адресного пространства,

но работает он, к сожалению, далеко не всегда, зачастую роняя при

неправильной настройке операционную систему.

Во-вторых, линейное адресное пространство подвержено

"засорению" - процессу, в ходе которого в нем образуются дырки,

которые невозможно использовать. Программы часто оперируют не

байтами и словами, а гораздо более крупными структурами,

занимающими десятки, сотни и даже миллионы байт информации.

Если мы использовали эту структуру, а затем необходимость в ней

отпала, то в памяти остается дыра, совпадающая по размерам и

расположению с местом, где лежали данные этой структуры. И

удастся ли сию дыру использовать - еще бабушка надвое сказала.

Иногда почти вся оперативная память состоит из дырок, не несущих

никакой практической пользы, и места для записи даже небольшого

объема данных не находится[Подобным особенно грешат

операционные системы и среды разработки компании Microsoft:

менеджер памяти, используемый в Windows, не столь эффективен,

как его UNIX-собратья, и "мусора" в памяти оставляет гораздо

больше. Иногда это приводит к тому, что нормально работающие на

UNIX программы, использующие вдобавок сравнительно небольшой

объем оперативной памяти, в MS Windows через некоторое время

вылетают с ошибкой Out of memory].

В-третьих, существует такая интересная техника, как маппинг файлов

на оперативную память. "Маппить" можно что угодно, причем это не

только самый быстрый, но и один из самых удобных способов

обработки файлов. Не нужно ничего читать из файла или записывать

в него, не нужно думать об эффективном кэшировании данных - все

происходит автоматически. Просто "мапнул" файл на память - и

находившиеся в нем данные волшебным образом мгновенно

оказались доступными приложению. В "настоящую" оперативную

память они будут подгружаться только при обращении к ним, а в

случае длительной "невостребованности" - вновь возвращаться на

жесткий диск, освобождая место для чего-нибудь более актуального.

Реализовать что-либо подобное "вручную" - практически

невозможно. Но, к сожалению, на двух гигабайтах адресного

пространства Windows особенно не развернешься[И на 4 Гбайт своп-

файла, которыми нас обычно ограничивает Windows (ругать так

ругать!), - зачастую тоже], поэтому техника маппинга задействуется

только тогда, когда высокая скорость обработки файлов для

приложения становится критичной.

Поэтому даже если бы в технологиях EM64T/AMD64 не было бы

ничего сверх возможности оперировать с 64-битными

указателями[Указатель на оперативную память (обычно просто

говорят: указатель) - это ячейка памяти, в которой записывается

номер другой ячейки. То есть, к примеру, мы можем как-то

использовать в программе это число (номер ячейки) - присваивать

его, изменять, увеличивать или уменьшать, а потом вызвать

специальную операцию "разыменования" - взятия данных,

расположенных по этому адресу в оперативной памяти. В C/C++ и

подобных языках программирования указатели выделены в

самостоятельный тип данных, и программист работает с ними

"вручную"; в других языках "арифметику" указателей от

программиста прячут, предлагая работать с более высокоуровневыми

абстракциями, однако в машинном коде и оперативной памяти

указатели встречаются почти всегда] на оперативную память, они по-

прежнему оставались бы востребованными и своего покупателя все

равно бы нашли. Но стоила бы в этом случае овчинка выделки?

Явные недостатки x86-64

Увы, нет. По крайней мере в ближайшие года три. Изменения

регистров общего назначения и системы адресации памяти - совсем

не то, что добавление новых регистров и новых инструкций для

работы с ними. Расширения никак не влияют на работу старых

программ, которые об их существовании и не догадываются; а вот

пройти мимо изменений использующихся на каждом шагу регистров

общего назначения - даже в уже существующих приложениях -

невозможно. Очень часто приложения явным или неявным образом

апеллируют к тому, что данные, которые они используют, имеют ту

или иную длину и неожиданный сюрприз в виде занимающего не 4, а

8 байт указателя на оперативную память для них почти всегда

фатален. Даже если программа не занимается "явным приведением

типов", превращая их в 32-битные целые числа и обратно (это из

сугубо программистских заморочек), то почти наверняка хоть где-

нибудь она работает со структурой данных, в которую одним из

компонентов входит тот самый указатель, и где для него отведено

строго четыре байта, зажатых слева и справа данными той же или

других структур. Так что подавляющее большинство существующих

32-битных программ в 64-битном режиме выполняться не будут.

Это не такая уж катастрофа, как может показаться: современные

процессоры умеют быстро переключаться между 32- и 64-битным

режимами, однако как минимум одно приложение, работающее на

64-битном компьютере, эти "нововведения" все-таки должно

поддерживать. Ибо если даже операционная система, заведующая

менеджментом виртуального адресного пространства, будет работать

в 32-битном режиме, то ради чего мы боролись? Поэтому

сформулируем "принцип номер один" для 64-битных систем: для

поддержки 64-битности операционная система тоже должна быть 64-

битной. Правда, объем переделок, которые для этого требуются,

велик, но не бесконечен - релизы UNIX-систем с поддержкой AMD64

появились всего лишь несколькими месяцами позже представления

новых систем, так что если бы этим дело и ограничилось, то особых

поводов для беспокойства не возникло. Но, к сожалению, драйверы

для операционных систем - это часть ОС, и, волей-неволей, они тоже

должны быть 64-битными. А поскольку драйверы пишут тысячи и

десятки тысяч "сторонних разработчиков", которым отнюдь не

улыбается одновременно поддерживать 32- и 64-битные версии, не

говоря о том, чтобы создавать драйвер для "железки", выпуск

которой уже два года как прекращен, то это уже очень серьезная

проблема, не решенная до сих пор[Сообществу OpenSource проще:

там почти ко всем драйверам идут исходники, и зачастую достаточно

простой перекомпиляции исходников, чтобы получить из 32-битной

версии 64-битную или наоборот. Юниксоиды вообще стараются по

возможности создавать переносимый код, который можно

использовать с минимумом изменений на разных платформах; но

даже если перекомпиляции недостаточно, то "модификация" этих

исходников с исправлением тонких мест, вызывающих проблемы с

64-битностью, в принципе доступна любому мало-мальски

грамотному программисту. Поэтому с "опенсорсными" 64-битными

драйверами особых проблем сейчас нет. А вот с "фирменными"

(вроде поддерживающего в Linux аппаратное ускорение OpenGL-

драйвера для видеокарт nVidia) есть, хотя вендоры и стараются

оперативно их решать].

Второе "слабое место" 64-битных процессоров в том, что обработка

64-битных данных заведомо требует больше времени, чем обработка

32-битных, и, что еще важнее, 64-битные программы и данные к ним

занимают в оперативной памяти гораздо больше места. А поскольку

оперативная память - ресурс медленный и дефицитный (кэш-память,

особенно кэши первого уровня, имеет конечные размеры), то вместе с

возросшей вычислительной сложностью это приводит к сильному

падению "чистой" производительности процессора в 64-битных

режимах. А что вы хотели, за все нужно платить, и в классическом

варианте за поддержку большого объема памяти, устранение

"проблемы мусора" и упрощение процедуры маппинга файлов на

память приходится расплачиваться сравнительно невысоким

быстродействием процессора, подсистемы оперативной памяти и

несовместимостью с ранее написанными драйверами. Разумеется, в

перспективе мы никуда от этого не уйдем, но сегодня потенциальные

недостатки 64-битности для обычного пользователя перевешивают ее

потенциальные достоинства.

Но кто сказал, что x86-64 - это только 64-битные указатели, команды

и регистры GPR?..

IA-32 versus x86-64

Переделывая почти весь процессор и весь набор поддерживаемых им

инструкций, мы все равно получаем несовместимость в 64-битном

режиме со старыми программами. Так почему бы заодно не

исправить ошибки предшественников и не убрать из x86 устаревшие

ограничения? 64-битный режим не просто улучшенная версия IA-32

ISA, фактически это следующая версия архитектуры x86, во многом

лишенная "родовых травм" этого семейства, начинавшегося с

микроконтроллеров и долгое время не претендовавшего на

"серьезное" использование.

Первое и, пожалуй, главное преимущество, которое получила

архитектура x86-64, - долгожданная поддержка шестнадцати

регистров общего назначения и шестнадцати регистров XMM. На

первый взгляд это чисто количественное изменение, но на самом деле

- принципиальная во всех отношениях доработка архитектуры IA-32.

Судите сами: у современного IA-32 восемь регистров общего

назначения (EAX, EBX, ECX, EDX, EDI, ESI, EBP и ESP), восемь 64-

битных регистров MMX (MMX0–MMX7) и восемь же регистров SSE

(XMM0–XMM7). Не замечаете ничего странного? Откуда вообще

взялась цифра восемь? Для ответа на этот вопрос нам потребуется

обратиться к "основам основ" - к формату x86-инструкций.

Каждая инструкция представляет собой длинную комбинацию из

пяти составляющих: а) опкода (operation code, opcode),

описывающего, что нужно сделать с данными, б) поля ModR/M, в

котором записывается "подвид" инструкции, режим адресации

памяти (как и у всякого CISC-процессорa, этих подвидов у x86 много)

и один или два регистра, используемых инструкцией, в) поля SIB

(Scale-Index-Base), в котором при некоторых режимах адресации

памяти записываются еще два регистра (база и индекс) и масштаб, г)

полей Displacement и Immediate, в них записываются используемые

инструкцией константы, д) набора "приставок" (prefixes),

позволяющих задать "нестандартные" режимы использования

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

остальные опциональны и могут отсутствовать[Теперь понимаете,

что имелось в виду под "непомерной сложностью декодирования

CISC-инструкций"?].

Оставим в стороне вопрос о том, для чего нужна столь сложная

конструкция и как она работает, и сосредоточимся на одном-

единственном интересующем нас аспекте: как в x86 кодируются

используемые инструкциями операнды. Смотрите: поля

Reg/Opcode[В принципе здесь может быть записан не регистр, а (для

некоторых инструкций) дополнительный опкод, указывающий на ту

или иную разновидность одной и той же инструкции] и R/M[Здесь

тоже не всегда записывается регистр - иногда это поле используют

для кодирования одной из 24 разновидностей режимов адресации

памяти. В x86 много подобных "тонкостей"] занимают по три бита,

поля Index и Base в SIB - тоже трехбитные. А трехбитных

комбинаций, как легко посчитать, всего восемь, именно столько

регистров может быть одновременно доступно любой программе. Так

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

8086, и с тех пор ничего не изменилось, хотя Pentium 4 отличается от

8086, как небо от земли. Восемь регистров современных Athlon и

Pentium не блажь разработчиков и не техническая необходимость, а

фундаментальное ограничение самого набора инструкций x86.

Что же делать, если нам хочется как-то обойти это ограничение, не

теряя совместимости со старыми приложениями? К счастью,

инженеры, проектировавшие x86 ISA, были очень талантливыми и

прозорливыми, а потому заложили в архитектуру возможность

вводить перед инструкциями приставки - специальные указатели, так

или иначе изменяющие значения инструкций. Скажем, приставка

LOCK говорит, что инструкция должна быть выполнена в "атомном"

режиме["Атомный" режим - это когда выполнение инструкции

гарантированно не будет прервано каким-нибудь внешним событием.

К примеру, если мы что-нибудь записываем в оперативную память,

то начиная с момента исполнения и до завершения атомной

инструкции никто "посторонний" не сможет ни записать в то же

место оперативной памяти, ни прочитать оттуда. Используется в

многопроцессорных системах для организации межпроцессорного

взаимодействия], приставки 2E и 2F подсказывают процессору,

произойдет условный переход или нет, а приставка 66 приказывает

переключаться между 16-битным и 32-битным представлением

данных в регистрах. Поэтому когда разработчикам x86-64

понадобилось добавить в архитектуру IA-32 поддержку 64-битности,

они сделали очень простую и в то же время гениальную вещь, введя

набор 64-битных приставок REX, которые не столько расширяют

возможности инструкций, сколько служат для кодирования

дополнительной информации в четырех своих полях. Поле REX.W

задает "размер" обрабатываемых данных: если здесь записан нолик,

то обрабатываемые регистры интерпретируются как 32-битные, если

единичка - то как 64-битные; а поля REX.R, REX.X и REX.B -

старшие биты, дополняющие трехбитные поля ModR/M.Reg,

SIB.Index и, в зависимости от ситуации, ModR/M.R/M или SIB.Base

соответственно. Знаю, что это звучит не слишком понятно, поэтому

тут же поясню, что это означает. На самом деле в 64-битном режиме

мы используем 4-битную кодировку регистров процессора, но три

младших регистровых бита записываем на их "традиционные" места

в инструкции, а старший бит - переносим в приставку REX, обходя

тем самым архитектурное ограничение. А заодно, помимо поддержки

восьми новых GPR-регистров R8–R15 и SSE-регистров XMM8–

XMM15, получаем возможность отключить 64-битные вычисления,

когда они нам не требуются, - и пропорционально сэкономить на

времени исполнения и занимаемом данными месте! И все это -

одним-единственным байтом!

Вторая группа усовершенствований - отказ от поддержки безнадежно

устаревших и давно не использующихся возможностей IA-32. В

расширенном режиме не поддерживаются Real Mode и Virtual 8086-

mode[Да-да, Virtual 8086 - это именно то, о чем вы сейчас подумали, -

полная имитация процессора Intel 8086. Много ли найдется людей,

которые пожалеют о его отсутствии?], и почти полностью отключена

сегментация[Поскольку читатель уже заскучал от обилия

технических фактов, не буду утомлять его описанием

сегментированной модели памяти 80286, скажу только, что

сегментация - это очень упрощенный аналог виртуальной памяти]

(хотя некоторые настройки сегмента CS и сегменты FS/GS все же

можно использовать); не поддерживаются инструкции, работавшие с

этими сегментами, и инструкции, оперировавшие BCD-числами[BCD

(Binary Coded Decimal) - это когда десятичное число записывается

шестнадцатеричными цифрами. Например, 54d - в виде 54h =

01010100b вместо традиционных 36h = 00110110b]. Все это позволяет

заметно облегчить процессору жизнь и в перспективе - повысить его

производительность. К примеру, отказ от сегментации позволяет при

обращении к оперативной памяти не вычислять линейный адрес и не

проверять его допустимость в рамках сегмента, а значит,

эффективность этой подсистемы при переходе к x86-64 существенно

возрастет.

"А как обстоят дела с совместимостью со старыми программами?" -

спросит читатель. Посмотрим: если обойтись без приставки REX, то

процессор будет считать, что все записанные там данные - нули, то

есть новые регистры не используются, а размер операндов

инструкции равен 32 битам, то есть старшие 32 бита каждого 64-

разрядного регистра при подобных вычислениях явным образом

забиваются нулями. Как легко догадаться, инструкция без префикса

REX даже в 64-битном режиме будет работать точно так же, как она

работала и в 32-битном; и если соблюдать меры предосторожности (в

частности, не выходить при адресации за границу "нижних 4 Гбайт"

виртуальной памяти, то даже в 64-битном режиме все программы

будут работать как и в 32-битном! Красивое решение? Мне кажется,

да. Если программе не требуется поддержка всяческих "64-

битностей", то она может запросто продолжать работать на

"физически" 64-битном процессоре в 32-битном режиме, не

используя ни 64-битные указатели, ни 64-битные вычисления, зато

"радуясь" удвоенному количеству регистров и другим улучшениям

x86.

К сожалению, "нет в мире счастья", и по кодировке префиксы REX

совпадают с шестнадцатью "сокращенными" инструкциями семейств

INC и DEC (увеличение или уменьшение содержимого регистра на

единичку). Вдобавок в 64-битном режиме не поддерживается ряд

инструкций и "режимов" x86 (о чем речь пойдет ниже), а для

нескольких инструкций изменены опкоды или их смысловая

нагрузка[К примеру, инструкция 90h в классическом x86 означает

XCHG EAX, EAX (поменять местами регистр EAX с регистром

EAX). Поскольку от перестановки двух одинаковых регистров их

содержимое не меняется, то эту комбинацию часто используют в

качестве однобайтной "пустышки" (NOP), которая ничего не

выполняет, зато занимает 1 байт машинного кода. Зачастую

некоторые инструкции хочется "выровнять" в оперативной памяти,

сделав так, чтобы они, например, не "пересекали 16-байтные

границы" (если этого не сделать, то при декодировании инструкции

возникнет "штраф", связанный с тем, что процессору придется

"склеивать" инструкцию из нескольких 16-байтных кусочков); и если,

скажем, эта инструкция - начало цикла, то непрерывная выплата

"штрафа" может существенно замедлить выполнение программы.

Вставка нескольких NOP’ов, "закрывающих" возникающие из-за

выравнивания "дырки" в коде, - обычная практика, однако в 64-

битном режиме процессор не просто переставит EAX с EAX местами,

а еще и заполнит старшие 32 бита регистра RAX нулями - и наша

инструкция уже не будет "настоящим" NOP’ом. Поэтому в x86-64

опкод 90h обрабатывается по-особому, всегда интерпретируясь как

NOP]; так что даже в "тепличных" 32-битных условиях

перекомпиляция программ для поддержки x86-64 все-таки требуется.

Но и унывать по этому поводу не приходится: получить все

преимущества от расширенного набора регистров без

перекомпиляции все равно невозможно, а если очень хочется

запустить 32-битное приложение, это можно сделать, временно

переведя процессор в "режим совместимости" (Compatibility Mode), в

котором полностью имитируется классический IA-32