Разрядность
Смею предположить, что не многие четко представляют, что такое разрядность процессора и что она вообще может быть разной. Но еще меньше могут с уверенностью ответить на вопрос заданный выше. Думаю, что среди пользователей персонального компьютера найдется не мало тех, кто даже не задумывался о том, какая разрядность его процессора, что это вообще означает и для чего она, собственно, нужна. И именно этой статьей мне хотелось бы заполнить данный пробел в ваших знаниях (если таковой имеется, хотя, думаю и «просвещенным» будет интересно прочитать нижеизложенное). Итак, приступим.
Центральный процессор, неотъемлемая часть нашего компьютера, представлен в виде относительно маленького чипа, внутри которого скрывается, как и огромный «физический мир» с его колоссально сложным строением, так и «логический мир» с не менее сложной структурой. При этом в своем развитии GPU архитектуры х86 прошел многое. Тут можно вспомнить и Intel 8008, который нас интересует только свой 8-битностью. Что означает следующие – регистры общего назначения (GPR – General Purpose Registers) могли хранить числа только такой разрядности. Впоследствии данную архитектуру «вывели в люди» 16-битные процессоры (8086 и 80286), которые в свою очередь уступили место 32-битным процессорам. Последние надолго застопорили дальнейшую «эволюцию», так как их возможности были более чем избыточными. Но как следствие постоянного развития и увеличения потребностей IT-индустрии, не так давно появились первые массовые 64-битные процессоры «улучшенной» архитектуры х86-64. На будущее оговорюсь – вести речь мы будем в основном только про 32- и 64-битную разрядность, так как только они актуальны на сегодняшний день.
В первую очередь разрядность процессора это не максимальный размер обрабатываемых данных. Например, обычные операции сложения и вычитания 64-битных чисел процессор научился выполнять еще со времен Pentium MMX, и даже древний i486 был в состоянии работать не только с 64-битными, но и с 80-битными числами. Также оставим за рамками инструкций MMX, x87 и SSE (последние вообще имеют длину 128 бит). Они работают с отдельными вычислительными блоками и специализированными регистрами процессора, развеваются своим путем и при этом не затрагивают сердце процессора (так называемый ISA (Instruction Set Architecture) – базовый набор инструкций) и базовые регистры общего назначения (GPR). Но для того чтобы вы поняли, что делает процессор, например, 64-разрядным я упрощенно распишу, как процессор оперирует числами.
Необходимые инструкции и данные поступают в блок целочисленных вычислений (ALU – Arithmetic Logic Unit) выполняющий все базовые арифметические операции, там производятся все нужные вычисления, и на выходе имеем нужный нам результат. Все предельно просто (конечно, я лукавлю, все стадии работы процессора и процессорных блоков настолько сложны и «объемны», что потянет на целую серию статей, но если вы желаете узнать, что собой представляет сердце вашего компьютера, и не страдаете страшной болезнью «много-букв-не-осилил», то жду ваших пожеланий – мыло должно быть в шапке статьи), и в этой схеме ничего не изменится, хоть будем оперировать числами в 4-битном представлении или же 64-битном. Процессор также произведет операцию и выдаст результат. Но это только часть картины, так как откуда-то все это должно поступить в ALU, а после выполнения действия, результат также должен куда-то деться. Конечное место, откуда и куда данные поступают, может быть чем угодно, будь-то винчестер или процессорный кэш, это не играет в данном случаи никакой роли. Главное то, что ни кэш, ни тем более оперативная память с жестким диском в силу физических ограничений не могут быть расположены вплотную к ALU, по этому своеобразным посредником выступают регистры общего назначения (GPR). Они работают на огромных скоростях, но по понятным причинам имеют крайне ограниченный конечный размер (вообще, GPR это целая история, так что основные технические вопросы мы благополучно опускаем). По сути ALU только их и «видит» и с ними работает (например, операцию умножения двух цифр он видит как умножение содержимого регистра A и B), и когда мы говорим о разрядности процессора, то в первую очередь подразумевается разрядность этих самых GPR (точнее могут ли они хранить 16, 32, или 64-бит числа). 
При этом основное отличие регистров GPR от всех остальных заключается в том, что их можно использовать для адресации оперативной памяти (или же проще – нумерации ячеек памяти 32- или 64-битными числами).
32
Дальнейший разговор мы будем вести в сравнениях 32 и 64-битных процессоров, это поможет нам лучше разобраться в сути вопроса, а также понять их плюсы и минусы.
Как я уже упоминал, GPR имеет четко фиксированный размер, и от этого размера зависит, какой объем данных может быть обработан за одну команду. Например, «современные» 32-битные процессоры могут складывать числа от 0 до ~4 миллионов за одну операцию, старенькие 16-битные могли за одну операцию складывать числа только до 65535, в свою очередь возможности древних 4-битных процессоров по нынешним меркам вообще смехотворны – максимальное число для обработки за одну команду у них составляло аж 15. Думаю, не стоит говорить, что числа, превышающие это заданное число, уже требовали для обработки свыше одной операции. Но при увеличении диапазона обрабатываемых чисел, кроме теоретического снижения времени на обработку больших чисел, мы получаем и более точные результаты, что для многих областей применения компьютеров является критичным. При этом увеличение разрядности влечет за собой и другие количественные изменения.
Так как современный персональный компьютер работает с линейной оперативной памятью, то соответственно мы можем представить ее в виде длиннющей такой ленты, состоящих из ячеек (в архитектуре х86 1 ячейка – 1 байт) имеющих свой номер, причем нумеровать мы можем их только до четко ограниченного придела. В 32-разрядной системе нумерация начинается с «ячейка 0» и заканчивается «ячейка 4294967295», но пронумеровать ячейки и, соответственно, обратиться к ним свыше этого числа мы никак не можем. И это выливается в практический вывод – имея 32-битный процессор, мы также имеем четкое ограничение в ~4.3 Гбайт памяти. В свою очередь с помощью 64-битного процессора такое ограничение можно существенно расширить, и в теории объем адресуемого пространства увеличивается до заоблачных 18 экзабайт (1 экзабайт = 1 миллиону терабайт, согласитесь, неплохой такой задел на будущее). Но, ясное дело, никто не ждал прихода 64-бит, поэтому всегда находились способы хоть и не «чисто», но обходить данное ограничение. Так, если процессор имеет поддержку длинных физических адресов, то удавалось значительно увеличить объем адресуемой памяти, и, например, 32-битный серверный процессор Xeon мог адресовать до 64 Гбайт (в архитектуре х86 существует режим Physical Address Extension, который использует 52-битную адресацию и позволяет адресовать до 4 петабайт данных, и ограничительными факторами выступали уже ограничения самой платформы). Такие уловки в основном успешно использовались на серверном рынке, потребности которого давно перевалили за заветные 4.3 Гбайт. Впрочем, подобные «костыли» выливались в падении чистой производительности, иногда превышающие десятки процентов.
Но вернемся непосредственно к оперативной памяти. К сожалению, часто упускают одну важную деталь – все программы в современных компьютерах работают никак ни с физической, а с виртуальной памятью. При этом мы просто можем нумеровать ячейки в совершенно произвольном порядке, и этот порядок, соответственно, не будет совпадать с физической последовательностью. Данный подход очень удобный в многозадачных операционных системах, так как можно по-разному пронумеровать ячейки и раздать их разным программам, которые «привыкли» именно к такому порядку и при этом считают, что вся память предназначена только им. Конечно, при этом в памяти неизбежно образуется самая, что ни есть каша (вообще, если развить тему каши в частности и слабых мест оперативной памяти в целом, то можно вспомнить, что существует довольно большая проблема, которая возникает, когда программа использовала некий объем памяти, а затем необходимость в этих данных пропадает. Как результат образуются своеобразные «дыры» (размер которых может быть просто огромным), причем не всегда можно повторно использовать данные участки памяти. Число этих дыр со временем может увеличиваться, а размер «полезного» места пропорционально уменьшается. В первую очередь такая проблема остро стоит в операционных системах Windows, так как ее менеджер памяти не настолько эффективен как в UNIX-подобных системах…), но на логическом уровне мы сохраняем линейность и монолитность, которую и видят программы. Также стоит учитывать тот факт, что при нумерации мы можем добавлять всяческие атрибуты (к примеру, только для чтения). Для нас будет интересен атрибут говорящий, что данные еще не загружены в оперативную память и при обращении к такой ячейке, можно применить технику свопинга – просто загрузить эти данные с жесткого диска. Вообще одна из особенностей виртуальной памяти это то, что с ее помощью можно обойти ограничения виде небольшого физического объема оперативной памяти (допустим, на 256/512 Мбайт оперативки сильно не разгуляться, впрочем, как и на 1 или 2 Гбайт – оперативной памяти не будет хватать всегда), так как под ней подразумевается не только оперативная память, но и внешние накопители (в первую очередь жесткие диски), которые также используются для хранения данных той или иной программы. И в зависимости от приоритетности и нужд самой программы эти данные могут быть загружены в быструю физическую оперативную память или же, наоборот, помещены на винчестер. Из этого вытекает следующее: в первую очередь ограничение 4.3 Гбайт это ограничение виртуальной памяти. Но, даже имея на первый взгляд довольно большой максимальный размер виртуальной памяти, не стоит забывать про «технические нужды» операционной системы. Например, всем известная ОС Windows обычно использует старший бит адреса и ограничивает все приложения 31-битом и всего-навсего ~2 Гб адресного пространства. А два гигабайта, согласитесь, по нынешним меркам уже не так впечатляют обычного пользователя.
64
Первое что следует сказать, рассматривая 64-битную разрядность, это то, что обработка 64-битных данных заведомо требует больше времени, нежели обработка 32-битных и при этом она занимают больше места в памяти. Это конечно связано с увеличением длины слова (оперировать небольшими структурами в виде одного байта процессор уже давно перестал, так что используются более крупные структуры – машинные слова). Приведу простой пример: со времен 16-битных процессоров, словом называют два байта, позже для совместимости со старыми программами 32-битное слово принимало вид двух 16-битных слов, т.е. в 32-разрядных компьютерах одно слово имело уже четыре байта. Таким образом, восьмибайтное слово соответствует 64-разрядным системам. Но это не значит, что 64-битные процессоры изначально проигрывают. В первую очередь они созданы именно для работы с 64-битными приложениями, так что последние на 64-битных компьютерах будут обрабатываться заведомо быстрее и точнее (я надеюсь, вы помните, что такое одинарная и двойная точность, когда-то мы это разбирали в серии статей «GPU: эволюция», так что повторяться не буду), чем на «имитации» 64-бит средствами 32-разрядных компьютеров. Впрочем, 64-разрядные процессоры имеют полную совместимость с «классическими» 32-битными программами, но об этом позже.
Многие уже наверно поняли одну из основных «особенностей» 64-битных компьютеров – подавляющее большинство 32-битных программ в 64-битной среде работать не будут. Это конечно связанно со всем, что мы говорили выше. Например, программа, которая привыкла, что вот этот участок данных занимает четко прописанный объем, и конечно для нее будет не совсем приятным сюрпризом удвоение такого объема. Еще можно вспомнить про другие примеры и более детально разобраться в причинах, но все сводится к одному – без доработки кода, программа, с очень большой вероятностью, не запустится в 64-битной среде (конечно, на самом деле, это не такая большая проблема – все современные 64-разрядные процессоры умеют «на лету» переключатся между 32- и 64-битными режимами, но об этом мы еще поговорим). И, конечно же, самым главным являет то, что операционная система также должна быть 64-битной. Но, тут проблема не велика, как может показаться, практически все популярные операционные системы давно обзавелись 64-битнымы версиями. Подобная ситуация и с большинством драйверов, которые, соответственно, также являются частью ОС. Найти 64-битную версию необходимых драйверов сегодня не составляет большего труда, правда бывают и исключения. Например, драйвера к железкам популярных и известных фирм можно найти в интернете (или на диске входящий в комплект поставки) буквально в течение нескольких секунд, а вот со специфичными или мало известными продуктами ситуация не такая радужная. Также проблематично будет найти нужные драйвера к различным периферийным устройствам (вебкамерам, сканерам, планшетам и т.д.). И проблема поиска драйверов может перерасти в неразрешимую дилемму, особенно если дело касается железок, которые уже как несколько лет вышли из производства или же продуктов так называемых «no name» производителей (например, ваш покорный слуга ради эксперимента откопал свой старенький модем – как и ожидалось, полтора часа упорных истязаний бедного Гугля никаких результатов не дали, впрочем, стоит сказать, что и 32-битных версий драйверов найдено не было).
С программным обеспечением ситуация схожа, впрочем, из-за разновидности и количества различных программ тут ситуация, когда пользователь столкнется с отсутствующей 64-битной версией нужной программы и с этим нечего нельзя будет сделать, куда вероятней. Конечно, все зависит от потребностей пользователя, практически все повседневно используемые программы имеют 64-битную версию, с серьезными и «тяжелыми» продуктами также все вроде нормально, а вот программы, которые я (может быть и не совсем корректно) охарактеризую как «халатные разработки» (допустим, софт созданные группой энтузиастов, которым как-то розово на 64-битную поддержку – для массовой 32-битной системы программу создали, и на этом спасибо. Или же разработчик по каким-то причинам не может сразу выпустить несколько версий одной программы (например, из-за сжатых сроков) и только потом, со временем, может снизойти до создания версии под различные разрядности, а вот когда это произойдет известно только инвесторам. Ну, и подобные примеры), зачастую могут оказаться за бортом. Но существует проблема другого рода: не все существующие 32-битные программы выиграют при переносе на 64-разрядность, просто для некоторых возможности 64-битности чересчур избыточны и они не будут востребованы в ближайшем будущем (точнее пока не появится совершенно новые версии данных программ, использующие все возможности 64-бит). Т.е. в отношении таких программ останется только один фактор, оговоренный выше – 64-битная программа, как правило, обрабатывается если не медленнее, то не как не быстрее 32-битных (при учете того, что и процессоры сопоставимы по производительности). Конечно, как я уже говорил, все зависит от потребностей конкретного пользователя, и если последнему в повседневной жизни приходится часто сталкиваться с программами, которые на 64-битных системах будут работать эффективней, то его выбор очевиден. Но на сегодняшний день таких пользователей пока не большинство.
Что касается линуксоидов (точнее, всех сторонников открытого софта), то проблемы поиска драйверов и программ для 64-разрядных компьютеров их практически не затрагивают, так как почти ко всему идут исходники, и перекомпиляция последних быстро решает все проблемы. И если даже по каким-то причинам перекомпиляции недостаточно, то небольшая ручная «доработка» исходников под силу мало-мальски грамотному программисту. Проблемы могут возникнуть в основном с «фирменными» драйверами (например, драйвера OpenGL), но разработчики по мере возможности решают подобные проблемы.
Теперь поговорим про совместимость. По сути любой 64-разрядный процессор имеет 3 режима работы. Не буду дотошно вникать в суть вопроса, лишь скажу, что с помощью ввода перед инструкциями специальных приставок (префикса REX), которые служат для кодирования информации в четырех своих полях, процессор, опираясь на данную информацию, понимает в каком режиме ему следует работать с программой, и в зависимости от значений прописанных в данных приставках меняет режим работы. Так, меняя значения всего одного байта (для кого-то один байт может показаться слишком много, ведь при учете того, что подобные приставки в коде программы могут встречаться неоднократно, то и измененная под 64-разрядность 32-битная программа, может значительно вырасти в размере (вплоть до ~10%). Но при учете того, что разработчики имели дело со специфическими особенностями архитектуры и повсеместными ограничениями, это вынужденный и по сути самый легкий и эффективный способ, иначе пришлось бы изменять всю архитектуру х86), в нашем случае прописываем там нолик, получаем режим, в котором процессор полностью совместим с 32-разрядностью (Legacy mode), т.е. все программы (в том числе и операционная система) являются 32-битными. Все возможности 64-битного процессора в таком режиме недоступны и старые добрые 32-битные программы чувствуют себя как дома, совершенно не замечая того, что работают на физическом 64-битном процессоре. При этом для программ процессор фактически никак не будет отличаться от 32-битного, за исключения уже чисто архитектурных доработок и улучшений. Если же в той приставке прописана единица (режим: Long mode), то нам будет доступно два режима работы в 64-битной среде. Зачем два? Поясняю. Если вы, по какой-то причине, работая на 64-битной операционной системе, хотите использовать 32-битное программное обеспечение, то для таких нужд существует режим совместимости (Compatibility mode). В данном режиме 32-битным программам, конечно, не будут доступны 64-битные возможности. А если же вы работаете только с 64-битной ОС и только с 64-битными программами, то и режим работы процессора у вас будет только 64-битным (64-bit mode). В последнем режиме мы имеем все прелести 64-битной системы со всеми вытекающими последствиями.
64 в кремнии
Для начала разберемся, как правильно называть 64-разрядную архитектуру х86, и, как вы понимаете, тут не все так просто. Например, данное расширение архитектуры х86 от AMD (Advanced Micro Devices) могут назвать AA-64 (AMD Architecture 64) и Hammer Architecture. Первое название было придумано популярным неофициальным справочником Sandpile.org (после первых предварительных спецификаций), второе же пошло от первого процессорного ядра с поддержкой 64-разрядности компании AMD. Но после выпуска первых 64-битных процессоров AMD, был принят официальный вариант – AMD64.
В свою очередь эту же технологию Intel первоначально «продвигала» под Yamhill Technology, Clackamas Technology и IA-32e (Intel Architecture – 32 Extended), но позже было введено официальное название EM64T (Extended Memory 64 Technology), которое сейчас наряду с Intel 64 (также является официальным) чаще всего встречается.
Помимо этого встречаются названия х86-64 и х64. Под первым часто подразумевают все 64-разрядные процессоры независимо от производителя. Под этим названием AMD опубликовала первые предварительные спецификации данной технологии. А вот x64 является официальным названием 64-битных версий операционных систем MS Windows и Solaris, и также используются как название данной архитектуры фирмами Microsoft и Sun Microsystems.
Что касается 64-разрядных процессоров, то у AMD это практически все настольные процессоры, начиная с Athlon 64 и заканчивая последними моделями Phenom, в том числе серверные Opteron и мобильные Turion. Исключением являются только процессоры семейства Sempron, которые поддерживают технологию AMD64 только со степпинга E, точнее практически все процессоры, начиная с осени 2005 года. У Intel это поздние модели Pentium 4 (все шестисотой серии и некоторые из пятисотой) и Celeron D (трехсотые модели, чей номер заканчивался на 6 и 1 и более поздние, в том числе и двухъядерные Celeron). Также расширенный набор инструкций х86-64 поддерживают Pentium D, Pentium Extreme Edition, Core 2 Duo и практически все более поздние одно- и многоядерные настольные, мобильные и серверные процессоры. Исключением являются мобильные процессоры Pentium M и Core Duo.
Определить является ли ваш процессор 64-разрядным или нет, не составляет большого труда. Всю нужную информацию о процессоре вы можете найти на сайте производителя, на коробке при покупке или же с помощью сторонних программ (CPU-Z, SiSoftware Sandra, x64 detector и т.п.).
Так, а теперь поговорим про основную тему данного раздела – отличия между 32- и 64-разрядными процессорами.
Выше я писал, что в 64-битном режиме мы имеем несовместимость со старыми программами, и хоть мы наизнанку вывернем процессор и перепишем все его инструкции, будем иметь тот же результат. Поэтому при разработке х86-64 инженеры небезосновательно посчитали, что раз дела обстоят именно так, то можно внести некоторые серьезные изменения и доработки в архитектуру х86. Как следствие, были убраны многие изъяны и ограничения в данной архитектуре. Первое и по сути одно из самых серьезных изменений – это увеличение количества регистров общего назначения с 8 до 16 (добавлены регистры R8 – R15). Плюс было увеличено число SIMD регистров (инструкции SSE), также с 8 до 16 (к XMM0 – XMM7 добавлены XMM8 – XMM15). Для того чтобы стало понятно, что на самом деле сделали разработчики, придется немного вспомнить особенности архитектуры х86. Но совершенно не хочется вести многостраничную разъяснительную работу по этому поводу (думаю кроме головной боли вам это нечего не даст, да еще чего доброго вы перестанете читать данную статью ), так что ограничусь только главными и нужными нам сейчас фактами.
В архитектуре х86 есть один очень существенный изъян, который на протяжении долгой жизни этой архитектуры «пинали» многие. Заключается он в том, что х86 процессоры могут иметь только 8 регистров общего назначение. Именно 8 регистров видит любой исполнительный код и именно 8 регистров может использовать любая программа. Конечно, я не хочу сказать, что в процессоре всего восемь регистров, нет, на самом дели за этой «восьмеркой» может скрываться около сотни регистров, которые можно переименовывать и в нужный момент подставлять вместо одного (или нескольких) основных. И это не прихоть злорадных дядей разработчиков, именно так требует основной формат х86-инструкций, и так было задумано несколько десятков лет назад во время проектирования Intel 8086 и это фундаментальное ограничение самого набора инструкций х86, которое не изменялось десятилетиями. Но как результат все это приводит к осознанному усложнению выполняющихся инструкций (и поверти мне, даже для понимания того, как в теории организуются инструкции нужно основательно посушить мозг), ведь как вы понимаете 8 регистров для подавляющего большинства алгоритмов крайне мало, и приходится постоянно выкручиваться, тратя при этом время и такты. Так что увеличение числа GPR – довольно большой шаг вперед и новая ступень развития архитектуры х86. На этом фоне особо изящно выглядит выбранный инженерами способ организации совместимости со старыми приложениями обходя архитектурные ограничения – всего одним байтом в коде программы мы можем заставлять работать процессор без новых регистров и 64-битности (про это мы говорили выше – режимы полной обратной совместимости, совместимости и режим 64-битности).
Также, возвращаясь к теме внесенных изменений в улучшенную архитектуру х86-64, следуют вспомнить, что были убраны такие давно не актуальные возможности как Real Mode и Virtual 8086-mode. В том числе практически полностью отказались от сегментации. Плюс еще ряд изменений, на которых нет сильной необходимости обострять внимания.
Пару слов о сегментации: сегментная модель организации памяти, по сути, является подвидом виртуальной памяти и в отличие от страничной организации со времен 16-битных процессоров практически не востребована. Но из-за того, что это неотъемлемая часть архитектуры х86 она передавалась по наследству от процессора к процессору. И вот светлые умы из AMD, разрабатывая архитектуру х86-64, посчитали, что сегментация не нужна, а даже на оборот обременяет процессор ненужными операциями, так как при обращении к оперативной памяти тот постоянно вычисляет линейный адрес и проверяет его доступность в рамках сегмента. Но совсем скоро оказалось, что без сегментации невозможно реализовать 64-разрядную виртуальную машину. Поняв это, AMD в урезанном виде вернула сегментацию, и даже сейчас, когда существуют средства аппаратной виртуализации (AMD-V (Virtualization) и Intel VT), AMD не спешит отказываться от сегментации. В свою очередь, Intel имея туже технологию с отсутствующей сегментацией, после обнаружение вышеописанной проблемы так и не вела ее назад. На практике это означает, что на процессорах Intel архитектуры х86-64 (если они, конечно, не поддерживают аппаратную виртуализацию Intel Virtualization Technology, или же если быть предельно точным – программа для виртуализации должна иметь поддержку Intel VT) невозможно загрузит 64-битную оперативную систему на виртуальной машине.
Думаю, не ошибусь, если скажу, что вы наверно уже подустали читать технические аспекты 64-битности, так что сразу переходим к следующему разделу нашей темы.
64 в массах
Тема массового перехода на 64-разрядность неоднократно подымалась и обговаривалась еще в конце прошлого века, уже тогда были довольно точно известны планы основных игроков процессорного рынка на этот счет. Но только в начале нынешнего, произошел настоящий информационный бум. Тема 64-битности и пути ее достижения повсеместно подымалась и обсуждалась во всевозможных IT-направленных СМИ, обговаривалась на различных выставках, конвентах и форумах. Волна различных публикаций и обсуждений не затухает и посей день. Этому в какой-то мере поспособствовала развернутая пиар-компания Intel. Именно эта компания одной из первых выпустила на массовый рынок первые 64-разрядные процессоры – Itanium. Вышедший весной 2001 года, данный процессор был направлен на серверный рынок, но из-за ряда причин оказался по сути провальным. Но такой поворот Intel предполагала, и спустя всего год вышел новый процессор Itanium 2, который хоть и разрабатывался в рамках единой идеологии с первым Itanium, но имел довольно большие архитектурные отличия (процессоры практически параллельно разрабатывали совершенно разные люди). При этом был намного более производительным и перспективным. Как результат, огромный рост продаж и большая популярность. Но данные процессоры не имеют непосредственного отношения к нашей статье. Itanium и Itanium 2 относятся к совершенно новой архитектуре IA-64 (кстати, это название могут иногда путать с архитектурой х86-64, но это в корне ошибочно), которая разрабатывалась на основе идеологии EPIC (Explicitly Parallel Instruction Computing) процессоров (в то время как х86 относятся к CISC с добавками от RISC процессоров). Я привел вышеизложенную информацию лишь, для того чтобы стало понятно, что первоначальный путь достижения «массовой 64-битности» от Intel заключался не в эволюционном, а в революционном развитии. Т.е. изначально Intel вообще не видела смыла в возне с х86 архитектурой (системы на базе данной архитектуры на тот момент являлись преобладающими в мире, впрочем такая картина сохраняется и по сей день) и предлагала переход на 64-разрядность вместе с новой архитектурой, не имеющей совместимости со старыми приложениями (не считая жутко медленной эмуляции 32-бит на IA-64). У некоторых складывалось впечатление, что этим шагов она вообще собирается в дальнейшем поставить крест на х86, так как упоминала о внедрение решений на основе IA-64 не только в серверную среду, но и другие рыночные ниши.
А вот AMD как раз решила идти эволюционным путем и развивать старую добрую архитектуру х86. Причины могут быть разными, от нехватки ресурсов на разработку совершенно новых архитектур и до понимания того, что данный путь является более рациональным и правильным. Но не будем разводить лирику и пытаться понять причины, преследуемые AMD и Intel, это все дела давно ушедших лет, да и результат нам хорошо известен, так что продолжим.
Итак, первым настольным 64-битным процессором расширенной архитектуры х86-64 стал вышедший осенью 2003 Athlon 64 от AMD на ядре Hammer (для справки: первыми процессорами данной архитектуры стали серверные Opteron, появившиеся на пол года раньше, они, кстати, базировались на том же ядре). Сам факт того, что данный процессор имел полную обратную совместимость с 32-разрядностью, привлек к себе внимание многих покупателей. И не смотря на то, что на момент выхода не было еще не одной 64-битной операционной системы, не говоря уже про 64-битное программное обеспечение, данные процессоры с самого начала продаж разбирался, как горячи пирожки. В первую очередь привлекало то, что за те же деньги покупатель получает процессор «на вырост» – можно спокойно работать на процессоре архитектуры х86-64 в 32-битной среде, и когда появится достаточное количество 64-битных продуктов, без лишних затрат перейти на новую разрядность.
Первыми на вооружение 64-битные процессоры (не считая серверный рынок, где данные процессоры прошли на ура и закрепились в нижнем сегменте данного рынка) взяли пользователи открытых операционных систем, так как 64-битнгые версии UNIX-подобных ОС появились почти сразу после выхода новых процессоров. В первую очередь это пользователи всех различных ресурсоемких проектных систем (Computer-Aided Design (CAD) Computer-Aided Engineering (CAE) систем и подобные), небольших исследовательских учреждений и фирм, работающих с медиа-контентом (работа с видео, разработка игр и т.д.), которые за небольшие капиталовложения могли вывести свои производительные мощности
