Компьютерра, 2005 № 41 (613) - [18]
Это не такая уж катастрофа, как может показаться: современные процессоры умеют быстро переключаться между 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?..
Переделывая почти весь процессор и весь набор поддерживаемых им инструкций, мы все равно получаем несовместимость в 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-инструкций»?].
