Компьютерра, 2005 № 41 (613) - [20]
К сожалению, «нет в мире счастья», и по кодировке префиксы 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.
В случае AMD - все новые CPU без исключения. Athlon 64, Mobile Athlon 64, Turion и Opteron поддерживают технологию AMD64 изначально; процессоры Sempron (изначально этой поддержки лишенные) - начиная с определенного степпинга (E) или определенной даты (осени 2005 года). Отличить «новые» Sempron от старых проще всего по логотипу на коробке: у 64-разрядных Sempron’ов на упаковке стоит значок AMD64.
В случае Intel технологию EM64T поддерживают только процессоры новых степпингов (начиная с "E") в исполнении LGA775. Pentium D, Pentium eXtreme Edition и Pentium 4 семейства 6xx поддерживают EM64T изначально; процессоры Xeon - начиная c 90-нм ядра Nocona; процессоры Pentium 4 семейства 5xx и Celeron D семейства 3xx - только те модели, номер которых заканчивается на шестерку или единичку. Pentium 4 Extreme Edition 3,73 ГГц тоже поддерживает EM64T. Все остальные модели (в частности, Pentium M и процессоры в исполнении Socket 478) технологию EM64T не поддерживают и в ближайшее время эту поддержку не получат.
Так стоит ли переходить на x86-64 или нет? Думаю, после всего вышеизложенного ответ понятен: без сомнения, стоит! Технология x86-64 действительно предоставляет все преимущества 64-битных систем, содержит ряд качественных улучшений по сравнению с «классической» IA-32 ISA, но главное - позволяет не использовать 64-битные вычисления там, где этого не требуется, и сохраняет полную совместимость с любым 32-битным софтом. А потому единственный серьезный довод против, который до сих пор мешает широкому распространению технологии, - это необходимость поддержки x86-64 операционной системой и использования редких и порой не до конца отлаженных и «недооптимизированных» 64-битных драйверов.
Благодарим компании AMD (за предоставление тестового набора Athlon 64 X2 4800+), MSI (за материнскую плату MSI K8N SLI) и сеть магазинов «Неоторг» (за видеокарту MSI GeForce 7800GT).
64-битный Linux
Операционные системы семейства *nix и особенно их разновидности с открытым исходным кодом никогда не испытывали затруднений с портированием на самые разные архитектуры. Unix вообще задумывалась как портируемая операционная система[Недаром же стандарт на Unix-системы называется POSIX - Portable Operation System Interface for computer environments], а множество добровольных помощников - неплохой способ сократить время отладки и тестирования новой разновидности «операционки» и драйверов для нее.
Именно это и позволило юниксоидам в полной мере использовать 64-битные x86-процессоры сразу же после того, как появились первые компиляторы, поддерживающие 64-битные инструкции x86-64. Благо что при желании собрать свой «64-битный» дистрибутив может любой человек, обладающий достаточными познаниями в программировании, организации и администрировании *nix-систем; а перекомпилировать «обычную» программу для того, чтобы она получила поддержку x86-64, в большинстве случаев может и обычный пользователь. В мире Unix-систем, в отличие от Microsoft Windows, поддержка технологии x86-64 происходит гораздо естественнее - если приложение (или драйвер) распространяется в «исходниках», то в большинстве случаев его достаточно «пересобрать» (заново откомпилировать программу); а если в «бинарниках» (в заранее откомпилированном виде) - то почти всегда этот бинарник представлен в целом ряде вариантов под разные версии *nix-систем, среди которых наверняка найдется подходящая версия под вашу конкретную операционную систему. Поскольку все вышесказанное относится и к драйверам (которые могут считаться пусть и не самостоятельными, но программами), то проблем с ними тоже, как правило, не возникает[Для некоторых устройств unix-драйверов попросту не существует - ни для 32-битных, ни для 64-битных версий операционных систем. Но эту ситуацию уже никак, естественно, не исправишь].
