x86-64

x86-64 (также известный как x64 , x86_64 , AMD64 и Intel 64 ) ^{[примечание 1]} — это 64-разрядное расширение архитектуры набора инструкций x86, впервые анонсированное в 1999 году. Оно представляет два новых режима работы: 64-разрядный режим и режим совместимости, а также новый четырехуровневый механизм страничного обмена .

В 64-битном режиме x86-64 поддерживает значительно большие объемы виртуальной и физической памяти по сравнению с 32-битными предшественниками, что позволяет программам использовать больше памяти для хранения данных. Архитектура расширяет число регистров общего назначения с 8 до 16, все полностью общего назначения, и расширяет их ширину до 64 бит.

Арифметика с плавающей точкой поддерживается обязательными инструкциями SSE2 в 64-битном режиме. Хотя старые регистры x87 FPU и MMX все еще доступны, они, как правило, заменяются набором из шестнадцати 128-битных векторных регистров (регистры XMM). Каждый из этих векторных регистров может хранить одно или два числа с плавающей точкой двойной точности , до четырех чисел с плавающей точкой одинарной точности или различные целочисленные форматы.

В 64-битном режиме инструкции изменяются для поддержки 64-битных операндов и 64-битного режима адресации .

Архитектура x86-64 определяет режим совместимости, который позволяет 16- и 32-разрядным пользовательским приложениям работать без изменений вместе с 64-разрядными приложениями, при условии, что 64-разрядная операционная система поддерживает их. ^{[11] [примечание 2]} Поскольку полные наборы инструкций x86-32 остаются реализованными на аппаратном уровне без необходимости эмуляции, эти старые исполняемые файлы могут работать с небольшим или нулевым снижением производительности, ^[13] в то время как более новые или модифицированные приложения могут использовать преимущества новых функций конструкции процессора для достижения улучшений производительности. Кроме того, процессоры, поддерживающие x86-64, по-прежнему включаются в реальном режиме для поддержания обратной совместимости с исходным процессором 8086 , как это было в случае с процессорами x86 с момента введения защищенного режима с 80286 .

Оригинальная спецификация, созданная AMD и выпущенная в 2000 году, была реализована AMD, Intel и VIA . Микроархитектура AMD K8 в процессорах Opteron и Athlon 64 была первой, в которой она была реализована. Это было первое значительное дополнение к архитектуре x86 , разработанное компанией, отличной от Intel. Intel была вынуждена последовать примеру и представить модифицированное семейство NetBurst , которое было программно совместимо со спецификациями AMD. VIA Technologies представила x86-64 в своей архитектуре VIA Isaiah с VIA Nano .

Архитектура x86-64 была быстро принята для настольных и портативных персональных компьютеров и серверов, которые обычно были сконфигурированы для 16 GiB ( гибибайт ) памяти или более. Она фактически заменила снятую с производства архитектуру Intel Itanium (ранее IA-64 ), которая изначально предназначалась для замены архитектуры x86. x86-64 и Itanium несовместимы на уровне собственного набора инструкций, а операционные системы и приложения, скомпилированные для одной архитектуры, не могут быть запущены на другой изначально.

AMD64 (также по-разному упоминаемая AMD в своей литературе и документации как «64-битная технология AMD» и «архитектура AMD x86-64») была создана как альтернатива радикально иной архитектуре IA-64, разработанной Intel и Hewlett-Packard , которая была обратно несовместима с IA-32 , 32-битной версией архитектуры x86 . AMD первоначально анонсировала AMD64 в 1999 году ^[14], а полная спецификация была доступна в августе 2000 года. ^[15] Поскольку AMD никогда не приглашалась стать стороной, вносящей вклад в архитектуру IA-64, и любое лицензирование казалось маловероятным, архитектура AMD64 с самого начала позиционировалась AMD как эволюционный способ добавления 64-битных вычислительных возможностей к существующей архитектуре x86 с поддержкой устаревшего 32-битного кода x86 , в отличие от подхода Intel по созданию совершенно новой, полностью несовместимой с x86 64-битной архитектуры с IA-64.

Первый процессор на базе AMD64 — Opteron — был выпущен в апреле 2003 года.

Процессоры AMD, реализующие архитектуру AMD64, включают Opteron , Athlon 64 , Athlon 64 X2 , Athlon 64 FX , Athlon II (с последующими «X2», «X3» или «X4» для указания количества ядер и моделей XLT), Turion 64 , Turion 64 X2 , Sempron (степпинг «Palermo» E6 и все модели «Manila»), Phenom (с последующими «X3» или «X4» для указания количества ядер), Phenom II (с последующими «X2», «X3», «X4» или «X6» для указания количества ядер), FX , Fusion/APU и Ryzen / Epyc .

Основной определяющей характеристикой AMD64 является наличие 64-битных регистров процессора общего назначения (например, rax ), 64-битных целочисленных арифметических и логических операций, а также 64-битных виртуальных адресов . ^[16] Разработчики воспользовались возможностью внести и другие улучшения.

Наиболее заметные изменения в 64-битных расширениях включают в себя:

Возможность работы с 64-битными целыми числами

Все регистры общего назначения (GPR) расширены с 32  до 64 бит, и все арифметические и логические операции, операции «память-регистр» и «регистр-память» и т. д. могут работать непосредственно с 64-битными целыми числами. Вставки и выталкивания в стеке по умолчанию имеют шаг в 8 байт, а указатели имеют ширину 8 байт.

Дополнительные регистры

В дополнение к увеличению размера регистров общего назначения, число именованных регистров общего назначения увеличено с восьми (т. е. eax , ebx , ecx , edx , esi , edi , esp , ebp ) в x86 до 16 (т. е . rax , rbx , rcx , rdx , rsi , rdi , rsp , rbp , r8 , r9 , r10 , r11 , r12 , r13 , r14 , r15 ). Таким образом, можно хранить больше локальных переменных в регистрах, а не в стеке, и позволить регистрам хранить часто используемые константы; аргументы для небольших и быстрых подпрограмм также могут передаваться в регистрах в большей степени.

AMD64 по-прежнему имеет меньше регистров, чем многие наборы инструкций RISC (например, Power ISA имеет 32 GPR; 64-битные ARM , RISC-V I, SPARC , Alpha , MIPS и PA-RISC имеют 31) или машины типа VLIW , такие как IA-64 (у которой 128 регистров). Однако реализация AMD64 может иметь гораздо больше внутренних регистров, чем число архитектурных регистров, предоставляемых набором инструкций (см. переименование регистров ). (Например, ядра AMD Zen имеют 168 64-битных целочисленных и 160 128-битных векторных физических внутренних регистров с плавающей точкой.)

Дополнительные регистры XMM (SSE)

Аналогично, количество 128-битных регистров XMM (используемых для потоковых инструкций SIMD ) также увеличено с 8 до 16.

Традиционный стек регистров FPU x87 не включен в расширение размера файла регистра в 64-битном режиме, по сравнению с регистрами XMM, используемыми SSE2, которые были расширены. Стек регистров x87 не является простым файлом регистра, хотя он и обеспечивает прямой доступ к отдельным регистрам с помощью низкозатратных операций обмена.

Большее виртуальное адресное пространство

Архитектура AMD64 определяет 64-битный формат виртуального адреса, из которых младшие 48 бит используются в текущих реализациях. ^{[11] : 120} Это позволяет использовать до 256  ТиБ (2,48 ^байт ) виртуального адресного пространства. Определение архитектуры позволяет увеличить этот предел в будущих реализациях до полных 64 бит, ^{[11] : 2  : 3  : 13  : 117  : 120} расширяя виртуальное адресное пространство до 16  ЭиБ (2,64 ^байт ). ^[17] Это сравнимо с 4  ГиБ ( ^2,32 байт) для x86. ^[18]

Это означает, что с очень большими файлами можно работать, отображая весь файл в адресное пространство процесса (что часто намного быстрее, чем работа с вызовами чтения/записи файла), вместо того, чтобы отображать области файла в адресное пространство и из него.

Большее физическое адресное пространство

Первоначальная реализация архитектуры AMD64 реализовала 40-битные физические адреса и, таким образом, могла адресовать до 1 ТиБ (2,40 ^байт ) ОЗУ. ^{[11] : 24} Текущие реализации архитектуры AMD64 (начиная с микроархитектуры AMD 10h ) расширяют это до 48-битных физических адресов ^[19] и, таким образом, могут адресовать до 256 ТиБ (2,48 ^байт ) ОЗУ. Архитектура позволяет расширить это до 52 бит в будущем ^{[11] : 24  [20]} (ограничено форматом записи таблицы страниц); ^{[11] : 131} это позволило бы адресовать до 4 ПиБ ОЗУ. Для сравнения, 32-битные процессоры x86 ограничены 64 ГиБ ОЗУ в режиме расширения физических адресов (PAE) ^[21] или 4 ГиБ ОЗУ без режима PAE. ^{[11] : 4}

Большее физическое адресное пространство в устаревшем режиме

При работе в устаревшем режиме архитектура AMD64 поддерживает режим Physical Address Extension (PAE), как и большинство современных процессоров x86, но AMD64 расширяет PAE с 36 бит до архитектурного предела в 52 бита физического адреса. Поэтому любая реализация допускает тот же предел физического адреса, что и в длинном режиме . ^{[11] : 24}

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

Инструкции теперь могут ссылаться на данные относительно указателя инструкции (регистр RIP). Это делает позиционно-независимый код , который часто используется в общих библиотеках и коде, загружаемом во время выполнения, более эффективным.

Инструкции SSE

Первоначальная архитектура AMD64 приняла SSE и SSE2 от Intel в качестве основных инструкций. Эти наборы инструкций обеспечивают векторное дополнение к скалярному x87 FPU для типов данных одинарной и двойной точности. SSE2 также предлагает целочисленные векторные операции для типов данных с точностью от 8 до 64 бит. Это делает векторные возможности архитектуры наравне с возможностями самых передовых процессоров x86 своего времени. Эти инструкции также можно использовать в 32-битном режиме. Распространение 64-битных процессоров сделало эти векторные возможности повсеместными в домашних компьютерах, что позволило улучшить стандарты 32-битных приложений. Например, 32-битная версия Windows 8 требует наличия инструкций SSE2. ^{[22] Инструкции} SSE3 и более поздние наборы инструкций Streaming SIMD Extensions не являются стандартными функциями архитектуры.

Бит «No-Execute»

Бит No-Execute или бит NX (бит 63 записи таблицы страниц) позволяет операционной системе указывать, какие страницы виртуального адресного пространства могут содержать исполняемый код, а какие нет. Попытка выполнить код со страницы, помеченной как «no execute», приведет к нарушению доступа к памяти, аналогичному попытке записи на страницу, доступную только для чтения. Это должно затруднить вредоносному коду захват контроля над системой с помощью атак « переполнение буфера » или «непроверенный буфер». Подобная функция доступна на процессорах x86 с 80286 в качестве атрибута дескрипторов сегментов ; однако это работает только для целого сегмента за раз.

Сегментированная адресация долгое время считалась устаревшим режимом работы, и все текущие операционные системы ПК фактически обходят ее, устанавливая для всех сегментов базовый адрес ноль и (в их 32-битной реализации) размер 4 ГиБ. AMD была первым поставщиком семейства x86, реализовавшим no-execute в режиме линейной адресации. Эта функция также доступна в устаревшем режиме на процессорах AMD64 и последних процессорах Intel x86, когда используется PAE.

Удаление старых функций

Несколько функций «системного программирования» архитектуры x86 либо не использовались, либо использовались недостаточно в современных операционных системах и либо недоступны на AMD64 в длинном (64-битном и совместимом) режиме, либо существуют только в ограниченной форме. К ним относятся сегментированная адресация (хотя сегменты FS и GS сохраняются в рудиментарной форме для использования в качестве указателей на внебазовые структуры операционной системы), ^{[11] : 70} механизм переключения состояния задачи и виртуальный режим 8086. Эти функции остаются полностью реализованными в «устаревшем режиме», позволяя этим процессорам запускать 32-битные и 16-битные операционные системы без модификаций. Некоторые инструкции, которые оказались редко полезными, не поддерживаются в 64-битном режиме, включая сохранение/восстановление сегментных регистров в стеке, сохранение/восстановление всех регистров (PUSHA/POPA), десятичная арифметика, инструкции BOUND и INTO, а также «дальние» переходы и вызовы с непосредственными операндами.

Хотя виртуальные адреса имеют ширину 64 бита в 64-битном режиме, текущие реализации (и все чипы, которые, как известно, находятся на стадии планирования) не позволяют использовать все виртуальное адресное пространство размером 2 ⁶⁴ байта (16  EiB ). Это было бы примерно в четыре миллиарда раз больше размера виртуального адресного пространства на 32-битных машинах. Большинству операционных систем и приложений не понадобится такое большое адресное пространство в обозримом будущем, поэтому реализация таких широких виртуальных адресов просто увеличит сложность и стоимость трансляции адресов без какой-либо реальной выгоды. Поэтому AMD решила, что в первых реализациях архитектуры только наименее значимые 48 бит виртуального адреса будут фактически использоваться в трансляции адресов ( поиск в таблице страниц ). ^{[11] : 120}

Кроме того, спецификация AMD требует, чтобы самые значимые 16 бит любого виртуального адреса, биты с 48 по 63, были копиями бита 47 (подобно расширению знака ). Если это требование не выполняется, процессор выдаст исключение. ^{[11] : 131} Адреса, соответствующие этому правилу, называются «канонической формой». ^{[11] : 130} Адреса канонической формы располагаются от 0 до 00007FFF'FFFFFFFF и от FFFF8000'00000000 до FFFFFFFF'FFFFFFFF, что в общей сложности составляет 256  ТиБ используемого виртуального адресного пространства. Это все еще в 65 536 раз больше виртуального адресного пространства 4 ГиБ 32-битных машин.

Эта функция облегчает последующую масштабируемость до истинной 64-битной адресации. Многие операционные системы (включая, но не ограничиваясь, семейством Windows NT ) берут себе половину адресного пространства с более высоким адресом (называемую пространством ядра ) и оставляют половину с более низким адресом ( пространство пользователя ) для кода приложения, стеков пользовательского режима, куч и других областей данных. ^[23] Конструкция «канонического адреса» гарантирует, что каждая совместимая с AMD64 реализация имеет, по сути, две половины памяти: нижняя половина начинается с 00000000'00000000 и «растет вверх» по мере того, как становится доступным больше виртуальных адресных битов, в то время как верхняя половина «пристыкована» к верхней части адресного пространства и растет вниз. Кроме того, обеспечение «канонической формы» адресов путем проверки неиспользуемых битов адреса предотвращает их использование операционной системой в тегированных указателях в качестве флагов, маркеров привилегий и т. д., поскольку такое использование может стать проблематичным при расширении архитектуры для реализации большего количества виртуальных битов адреса.

Первые версии Windows для x64 даже не использовали все 256 ТиБ; они были ограничены всего 8 ТиБ пользовательского пространства и 8 ТиБ пространства ядра. ^[23] Windows не поддерживала все 48-битное адресное пространство до Windows 8.1 , которая была выпущена в октябре 2013 года. ^[23]

64-битный режим адресации (« длинный режим ») является надмножеством расширений физических адресов (PAE); из-за этого размеры  страниц могут составлять 4 КиБ ( ^2,12 байт) или 2  МиБ ( ^2,21 байт). ^{[11] : 120} Длинный режим также поддерживает размеры страниц 1  ГиБ ( ^2,30 байт). ^{[11] : 120} Вместо трехуровневой системы таблиц страниц , используемой системами в режиме PAE, системы, работающие в длинном режиме, используют четыре уровня таблиц страниц: Таблица указателей каталогов страниц PAE расширена с четырех записей до 512, а также добавлена ​​дополнительная таблица Page-Map Level 4 (PML4) , содержащая 512 записей в 48-битных реализациях. ^{[11] : 131} Полная иерархия отображения страниц размером 4 КиБ для всего 48-битного пространства заняла бы чуть больше 512  ГиБ памяти (около 0,195% от 256 ТиБ виртуального пространства).

64-битная запись таблицы страниц

Биты:	63	62 … 52											51 … 32
Содержание:	НХ	сдержанный											Бит 51…32 базового адреса
Биты:	31 … 12																				11 … 9			8	7	6	5	4	3	2	1	0
Содержание:	Бит 31…12 базового адреса																				игн.			Г	ПАТ	Д	А	PCD	ПВТ	НАС	Ч/З	П

Intel реализовала схему с 5-уровневой таблицей страниц , которая позволяет процессорам Intel 64 поддерживать 57-битные адреса и, в свою очередь, виртуальное адресное пространство размером 128  ПиБ . ^[24] Дальнейшие расширения могут разрешить полное 64-битное виртуальное адресное пространство и физическую память с 12-битными дескрипторами таблицы страниц и 16- или 21-битными смещениями памяти для размеров выделения страниц 64 КиБ и 2 МиБ; запись таблицы страниц будет расширена до 128 бит для поддержки дополнительных аппаратных флагов для размера страницы и размера виртуального адресного пространства. ^[25]

Операционная система также может ограничивать виртуальное адресное пространство. Подробности, где это применимо, приведены в разделе «Совместимость и характеристики операционной системы».

Текущие процессоры AMD64 поддерживают физическое адресное пространство до 248 ^байт ОЗУ или 256  ТиБ . ^[19] Однако по состоянию на 2020 год ^{[обновлять]}не было известно ни одной материнской платы x86-64 , поддерживающей 256 ТиБ ОЗУ. ^{[26] [27] [28] [29] [ проверка не пройдена ]} Операционная система может накладывать дополнительные ограничения на объем ОЗУ, который можно использовать или поддерживать. Подробности по этому вопросу приведены в разделе «Совместимость и характеристики операционных систем» этой статьи.

Архитектура имеет два основных режима работы: длительный режим и унаследованный режим.

Режим Long — это основной режим работы архитектуры, он представляет собой комбинацию собственного 64-битного режима процессора и комбинированного 32-битного и 16-битного режима совместимости. Он используется 64-битными операционными системами. В 64-битной операционной системе 64-битные программы работают в 64-битном режиме, а 32-битные и 16-битные приложения защищенного режима (которым не нужно использовать ни реальный режим, ни виртуальный режим 8086 для выполнения в любое время) работают в режиме совместимости. Программы реального режима и программы, которые используют виртуальный режим 8086 в любое время, не могут работать в режиме long, если эти режимы не эмулируются программно. ^{[11] : 11} Однако такие программы могут быть запущены из операционной системы, работающей в режиме long на процессорах, поддерживающих VT-x или AMD-V, путем создания виртуального процессора, работающего в желаемом режиме.

Поскольку базовый набор инструкций тот же, производительность при выполнении защищенного режима кода x86 практически не снижается. Это отличается от IA-64 от Intel , где различия в базовом наборе инструкций означают, что запуск 32-битного кода должен выполняться либо в эмуляции x86 (что делает процесс медленнее), либо с помощью выделенного сопроцессора x86. Однако на платформе x86-64 многие приложения x86 могут выиграть от 64-битной перекомпиляции из-за дополнительных регистров в 64-битном коде и гарантированной поддержки FPU на основе SSE2, которую компилятор может использовать для оптимизации. Однако приложения, которые регулярно обрабатывают целые числа шире 32 бит, такие как криптографические алгоритмы, потребуют переписывания кода, обрабатывающего огромные целые числа, чтобы воспользоваться преимуществами 64-битных регистров.

Режим Legacy — это режим, в котором находится процессор, когда он не находится в режиме long. ^{[11] : 14} В этом режиме процессор действует как старый процессор x86, и может выполняться только 16- и 32-битный код. Режим Legacy допускает максимум 32-битную виртуальную адресацию, что ограничивает виртуальное адресное пространство 4 ГиБ. ^{[11] : 14  : 24  : 118} 64-битные программы не могут быть запущены из режима legacy.

Защищенный режим преобразован в подрежим устаревшего режима. ^{[11] : 14} Это подрежим, в котором работают 32-разрядные операционные системы и 16-разрядные операционные системы защищенного режима при запуске на процессоре x86-64. ^{[11] : 14}

Реальный режим — это начальный режим работы, когда процессор инициализируется, и является подрежимом устаревшего режима. Он обратно совместим с оригинальными процессорами Intel 8086 и Intel 8088. Реальный режим в основном используется сегодня загрузчиками операционных систем, которые требуются архитектурой для настройки деталей виртуальной памяти перед переходом в более высокие режимы. Этот режим также используется любой операционной системой, которой необходимо взаимодействовать с системной прошивкой с помощью традиционного интерфейса в стиле BIOS . ^[30]

Intel 64 — это реализация x86-64 компанией Intel, используемая и реализованная в различных процессорах, производимых Intel.

Исторически AMD разрабатывала и производила процессоры с наборами инструкций, созданными по образцу оригинальных разработок Intel, но с появлением x86-64 роли поменялись местами: Intel оказалась в ситуации, когда ей пришлось принять ISA , созданную AMD в качестве расширения собственной линейки процессоров Intel x86.

Первоначально проект Intel носил кодовое название Yamhill ^[31] (в честь реки Ямхилл в долине Уилламетт в штате Орегон). После нескольких лет отрицания его существования, Intel объявила на IDF в феврале 2004 года , что проект действительно находится в стадии реализации. Председатель Intel в то время, Крейг Барретт , признал, что это был один из их самых плохо охраняемых секретов. ^{[32] [33]}

Название Intel для этого набора инструкций менялось несколько раз. Название, используемое на IDF, было CT ^[34] (предположительно ^{[ оригинальное исследование? ]} для Clackamas Technology , еще одно кодовое название от реки Орегон ); в течение нескольких недель они начали называть его IA-32e (для расширений IA-32 ), а в марте 2004 года представили «официальное» название EM64T (Extended Memory 64 Technology). В конце 2006 года Intel начала вместо этого использовать название Intel 64 для своей реализации, параллельно с использованием AMD названия AMD64. ^[35]

Первым процессором, реализовавшим Intel 64, был многосокетный процессор Xeon под кодовым названием Nocona в июне 2004 года. Напротив, начальные чипы Prescott (февраль 2004 года) не поддерживали эту функцию. Впоследствии Intel начала продавать Pentium 4 с поддержкой Intel 64, используя версию E0 ядра Prescott, продаваемую на рынке OEM как Pentium 4, модель F. Версия E0 также добавляет eXecute Disable (XD) (название Intel для бита NX ) к Intel 64 и была включена в тогдашний текущий Xeon под кодовым названием Irwindale . Официальным запуском Intel Intel 64 (под названием EM64T в то время) в массовых настольных процессорах был степпинг N0 Prescott-2M.

Первым мобильным процессором Intel , реализующим Intel 64, стала версия процессора Core 2 Merom , выпущенная 27 июля 2006 года. Ни один из более ранних процессоров Intel для ноутбуков ( Core Duo , Pentium M , Celeron M , Mobile Pentium 4 ) не реализует Intel 64.

Процессоры Intel, реализующие архитектуру Intel64, включают Pentium 4 серии F/5x1, 506 и 516, Celeron D моделей 3x1, 3x6, 355, 347, 352, 360 и 365 и все более поздние Celeron , все модели Xeon начиная с « Nocona », все модели процессоров Pentium Dual-Core начиная с « Merom-2M », Atom 230, 330, D410, D425, D510, D525, N450, N455, N470, N475, N550, N570, N2600 и N2800, все версии процессоров Pentium D , Pentium Extreme Edition , Core 2 , Core i9 , Core i7 , Core i5 и Core i3 , а также процессоры Xeon Процессоры серии Phi 7200.

X86S был упрощением x86-64, впервые предложенным Intel в мае 2023 года. ^[36] Новая архитектура убрала бы поддержку 16- и 32-разрядных операционных систем, хотя 32-разрядные программы по-прежнему работали бы под управлением 64-разрядной ОС. Совместимый процессор больше не имел бы устаревшего режима и запускался бы непосредственно в 64-разрядном длинном режиме . Был бы способ переключиться на 5-уровневую подкачку без прохождения невыгружаемого режима. Конкретные удаленные функции включали: ^[37]

Проект спецификации получил несколько обновлений, достигнув версии 1.2 к июню 2024 года. В конечном итоге он был заброшен в декабре 2024 года после формирования Консультативной группы по экосистеме x86 компаниями Intel и AMD. ^[38]

Advanced Performance Extensions — это предложение Intel 2023 года по новым инструкциям и 16 дополнительным регистрам общего назначения.

VIA Technologies представила свою первую реализацию архитектуры x86-64 в 2008 году после пяти лет разработки ее подразделением CPU Centaur Technology . ^[39] Под кодовым названием «Isaiah» 64-битная архитектура была представлена ​​24 января 2008 года, ^[40] и запущена 29 мая под торговой маркой VIA Nano . ^[41]

Процессор поддерживает ряд специфичных для VIA расширений x86, разработанных для повышения эффективности в маломощных устройствах. Ожидается, что архитектура Isaiah будет в два раза быстрее в целочисленной производительности и в четыре раза быстрее в производительности с плавающей точкой , чем предыдущее поколение VIA Esther при эквивалентной тактовой частоте . Потребляемая мощность также, как ожидается, будет на одном уровне с процессорами VIA предыдущего поколения, с тепловой расчетной мощностью в диапазоне от 5 Вт до 25 Вт. ^[42] Будучи совершенно новым дизайном, архитектура Isaiah была построена с поддержкой таких функций, как набор инструкций x86-64 и виртуализация x86 , которые были недоступны в его предшественниках, линейке VIA C7 , при сохранении их расширений шифрования.

В 2020 году в результате сотрудничества AMD, Intel, Red Hat и SUSE были определены три уровня микроархитектуры (или уровня функций) поверх базовой линии x86-64: x86-64-v2, x86-64-v3 и x86-64-v4. ^{[43] [44]} Эти уровни определяют конкретные функции, которые могут быть использованы программистами для обеспечения оптимизации времени компиляции. Функции, предоставляемые каждым уровнем, следующие: ^[45]

Уровни функций микроархитектуры x86-64 также можно найти как AMD64-v1, AMD64-v2 .. или AMD64_v1 .. в настройках, где используется номенклатура "AMD64". Они используются как синонимы с номенклатурой x86-64-vX и, таким образом, функционально идентичны. Например, документация языка Go или дистрибутив Fedora Linux.

Все уровни включают функции, найденные в предыдущих уровнях. Расширения набора инструкций, не связанные с вычислениями общего назначения, включая AES-NI и RDRAND , исключены из требований уровня.

В любом дистрибутиве Linux x86_64 все уровни функций x86_64, поддерживаемые ЦП, можно проверить с помощью команды: ld.so --helpРезультат будет виден в конце вывода команды:

‎

Подкаталоги  каталогов glibc  -hwcaps в порядке приоритета :    x86-64-v4x86-64-v3 ( поддерживается, искал )  x86-64-v2 ( поддерживается, искал )  

В данном случае уровень функций x86-64-v4 не поддерживается ЦП, но x86-64-v3 и x86-64-v2 поддерживаются, что означает, что этот ЦП не поддерживает AVX512, требуемый на уровне v4.

Хотя они почти идентичны, между двумя наборами инструкций имеются некоторые различия в семантике нескольких редко используемых машинных инструкций (или ситуаций), которые в основном используются для системного программирования . ^[48] Компиляторы обычно создают исполняемые файлы (т. е. машинный код ), которые избегают каких-либо различий, по крайней мере, для обычных прикладных программ . Поэтому это представляет интерес в основном для разработчиков компиляторов, операционных систем и т. п., которым приходится иметь дело с индивидуальными и специальными системными инструкциями.

• Intel 64 допускает SYSCALL/ SYSRETтолько в 64-битном режиме (не в режиме совместимости), ^[49] и допускает SYSENTER/ SYSEXITв обоих режимах. ^[50] AMD64 не допускает SYSENTER/ SYSEXITв обоих подрежимах длинного режима . ^{[11] : 33}
• При возврате к неканоническому адресу с помощью SYSRETпроцессоры AMD64 выполняют обработчик сбоев общей защиты на уровне привилегий 3, ^[51] тогда как на процессорах Intel 64 он выполняется на уровне привилегий 0. ^[52]
• AMD64 требует другого формата обновления микрокода и управления MSR (регистрами, специфичными для модели), в то время как Intel 64 реализует обновление микрокода без изменений по сравнению с 32-разрядными процессорами.
• В Intel 64 отсутствуют некоторые MSR, которые считаются архитектурными в AMD64. К ним относятся SYSCFG, TOP_MEM, и TOP_MEM2.
• В Intel 64 отсутствует возможность сохранения и восстановления сокращенной (и, следовательно, более быстрой) версии состояния с плавающей точкой (включая инструкции FXSAVEи FXRSTOR). ^{[ необходимо разъяснение ]}
• В 64-битном режиме ближние переходы с префиксом 66H (переопределение размера операнда) ведут себя по-другому. Intel 64 игнорирует этот префикс: инструкция имеет 32-битное расширенное смещение знака, а указатель инструкции не усекается. AMD64 использует 16-битное поле смещения в инструкции и очищает верхние 48 бит указателя инструкции.
• На Intel 64, но не на AMD64, REX.Wпрефикс можно использовать с инструкциями дальнего указателя ( LFS, LGS, LSS, JMP FAR, CALL FAR) для увеличения размера аргумента дальнего указателя до 80 бит (64-битное смещение + 16-битный сегмент).
• Если MOVSXDинструкция выполняется с операндом-источником памяти и размером операнда 16 бит, то доступ к операнду памяти будет осуществляться с помощью 16-битного чтения на Intel 64, но с помощью 32-битного чтения на AMD64.
• Инструкции FCOMI/ FCOMIP/ FUCOMI/ FUCOMIP(сравнение с плавающей точкой x87) очищают биты OF, SF и AF EFLAGS на Intel 64, но оставляют эти биты флагов неизменными на AMD64.
• Для инструкций VMASKMOVPS/ VMASKMOVPD/ VPMASKMOVD/ VPMASKMOVQ(маскированное перемещение AVX/AVX2 в память/из памяти) архитектура Intel 64 гарантирует, что инструкции не приведут к ошибкам памяти (например, ошибкам страниц и ошибкам сегментации) для любых полос с нулевой маской, тогда как AMD64 не дает такой гарантии.
• Если RDRANDинструкции не удается получить случайное число (на что указывает EFLAGS .CF=0), архитектурно гарантированно, что целевой регистр будет установлен в 0 на Intel 64, но не на AMD64.
• Для инструкций VPINSRDи VPEXTRD(вставка/извлечение векторной полосы AVX) за пределами 64-битного режима AMD64 требует, чтобы инструкции были закодированы с помощью VEX.W =0, в то время как Intel 64 также принимает кодировки с VEX.W=1. (В 64-битном режиме и AMD64, и Intel 64 требуют VEX.W=0.)
• Код 0F 0D /rоперации с полем Mod байта ModR/M11b , установленным на, является зарезервированным NOP на Intel 64 ^[53] , но вызовет #UD (исключение недопустимого кода операции) на AMD64. ^[54]
• Гарантии упорядочивания, предоставляемые некоторыми инструкциями упорядочивания памяти, такими как LFENCEи , MFENCEразличаются в Intel 64 и AMD64:
  • LFENCEявляется диспетчерской сериализацией (что позволяет использовать ее в качестве ограждения для спекуляций ) на Intel 64, но архитектурно не гарантирует диспетчерскую сериализацию на AMD64. ^[55]
  • MFENCEявляется полностью сериализуемой инструкцией (включая сериализацию выборки инструкций) на AMD64, но не на Intel 64.
  • Инструкции MOVCR8 и CR8 INVPCIDсериализуются на AMD64, но не на Intel 64.
  • Инструкция LMSWсериализуется на Intel 64, но не на AMD64.

This section needs to be updated. The reason given is: future tense relating to processors that have been out for years, dates with day and month but no year. Please help update this article to reflect recent events or newly available information. (January 2023)

• Процессоры AMD64 до Revision F ^[56] (отличающиеся переключением с памяти DDR на DDR2 и новыми сокетами AM2 , F и S1 ) 2006 года не имели этой CMPXCHG16Bинструкции, которая является расширением инструкции CMPXCHG8B, присутствующей в большинстве процессоров после 80486. Подобно CMPXCHG8B, CMPXCHG16Bпозволяет выполнять атомарные операции над окта-словами (128-битными значениями). Это полезно для параллельных алгоритмов, которые используют сравнение и обмен данными, превышающими размер указателя, что распространено в алгоритмах без блокировки и без ожидания . Без CMPXCHG16Bнее необходимо использовать обходные пути, такие как критический раздел или альтернативные подходы без блокировки. ^[57] Его отсутствие также не позволяет 64-битным Windows до Windows 8.1 иметь адресное пространство пользовательского режима больше 8  ТиБ . ^[58] 64-битной версии Windows 8.1 требуется эта инструкция. ^[59]
• Ранние процессоры AMD64 и Intel 64 не имели LAHFинструкций SAHFв 64-битном режиме. AMD представила эти инструкции (также в 64-битном режиме) со своими 90 нм (ревизия D) процессорами, начиная с Athlon 64 в октябре 2004 года. ^{[60] [61]} Intel представила инструкции в октябре 2005 года с 0F47h ​​и более поздними версиями NetBurst . ^[67] 64-битная версия Windows 8.1 требует эту функцию. ^[59]
• Ранние процессоры Intel с Intel 64 также не имеют бита NX архитектуры AMD64. Он был добавлен в степпинге E0 (0F41h) Pentium 4 в октябре 2004 года. ^[68] Эта функция требуется для всех версий Windows 8.
• Ранние реализации Intel 64 имели 36-битную (64 ГиБ) физическую адресацию памяти, в то время как оригинальные реализации AMD64 имели 40-битную (1  ТиБ ) физическую адресацию. Intel впервые использовала 40-битную физическую адресацию в Xeon MP ( Potomac ), выпущенном 29 марта 2005 года. ^[69] Разница не в различии видимых пользователю ISA. В 2007 году Opteron на базе AMD 10h стал первым, кто предоставил 48-битное (256 ТиБ) физическое адресное пространство. ^{[70] [71]} Физическая адресация Intel 64 была расширена до 44 бит (16 ТиБ) в Nehalem-EX в 2010 году ^[72] и до 46 бит (64 ТиБ) в Sandy Bridge E в 2011 году. ^{[73] [74]} С процессорами Ice Lake 3-го поколения Xeon Scalable компания Intel увеличила виртуальную адресацию до 57 бит (128  ПиБ ) и физическую до 52 бит (4 ПиБ) в 2021 году, что потребовало 5-уровневого страничного обмена . ^[75] В следующем году AMD64 добавила то же самое в 4-м поколении EPYC (Genoa). ^[76] Несерверные процессоры дольше сохраняют меньшие адресные пространства.
• На всех процессорах AMD64 инструкции BSFи BSRпри задании исходного значения 0 оставят свой регистр назначения неизмененным. Это в основном касается и процессоров Intel 64, за исключением того, что на некоторых старых процессорах Intel 64 выполнение этих инструкций с размером операнда 32 бита очистит верхние 32 бита их регистра назначения даже при исходном значении 0 (при этом нижние 32 бита останутся неизменными.) ^[77]
• Процессоры AMD64, начиная с Opteron Rev. E и Athlon 64 Rev. D, вновь ввели ограниченную поддержку сегментации с помощью бита Long Mode Segment Limit Enable (LMSLE) для упрощения виртуализации 64-битных гостевых систем. ^{[78] [79]} Поддержка LMLSE была удалена в процессоре Zen 3. ^[80]
• На всех процессорах Intel 64 CLFLUSHупорядочивается относительно SFENCE- это также касается новых процессоров AMD64 (Zen 1 и более поздние версии). На старых процессорах AMD64 наложение порядка на CLFLUSHинструкцию вместо требуемого MFENCE.

В суперкомпьютерах , отслеживаемых TOP500 , появление 64-битных расширений для архитектуры x86 позволило 64-битным процессорам x86 от AMD и Intel заменить большинство архитектур RISC-процессоров, ранее использовавшихся в таких системах (включая PA-RISC , SPARC , Alpha и другие), а также 32-битную x86, хотя сама Intel изначально безуспешно пыталась заменить x86 на новую несовместимую 64-битную архитектуру в процессоре Itanium .

По состоянию на 2023 год ^[update]суперкомпьютер на базе HPE EPYC под названием Frontier занимает первое место. Первый суперкомпьютер на базе ARM появился в списке в 2018 году ^[82] , а в последние годы сопроцессоры не-CPU архитектуры ( GPGPU ) также играют большую роль в производительности. Сопроцессоры Intel Xeon Phi "Knights Corner" , которые реализуют подмножество x86-64 с некоторыми векторными расширениями ^[83] , также используются вместе с процессорами x86-64 в суперкомпьютере Tianhe-2 . ^[84]

Следующие операционные системы и выпуски поддерживают архитектуру x86-64 в длинном режиме .

Предварительная работа по созданию инфраструктуры была начата в феврале 2004 года для порта x86-64. ^[85] Позднее эта разработка застопорилась. Разработка возобновилась в июле 2007 года ^[86] и продолжилась во время Google Summer of Code 2008 и SoC 2009. ^{[87] [88]} Первым официальным релизом, содержащим поддержку x86-64, стала версия 2.4. ^[89]

FreeBSD впервые добавила поддержку x86-64 под названием "amd64" в качестве экспериментальной архитектуры в 5.1-RELEASE в июне 2003 года. Она была включена в качестве стандартной архитектуры дистрибутива с 5.2-RELEASE в январе 2004 года. С тех пор FreeBSD обозначила ее как платформу Tier 1. Версия 6.0-RELEASE устранила некоторые странности с запуском исполняемых файлов x86 под amd64, и большинство драйверов работают так же, как и на архитектуре x86. В настоящее время ведется работа по более полной интеграции двоичного интерфейса приложений x86 (ABI) таким же образом, как в настоящее время работает совместимость Linux 32-битного ABI.

Поддержка архитектуры x86-64 была впервые включена в исходное дерево NetBSD 19 июня 2001 года. Начиная с NetBSD 2.0, выпущенной 9 декабря 2004 года, NetBSD/amd64 является полностью интегрированным и поддерживаемым портом. 32-битный код по-прежнему поддерживается в 64-битном режиме с уровнем совместимости ядра netbsd-32 для 32-битных системных вызовов. Бит NX используется для предоставления неисполняемого стека и кучи с гранулярностью по страницам (гранулярность по сегментам используется на 32-битной x86).

OpenBSD поддерживает AMD64 с OpenBSD 3.5, выпущенной 1 мая 2004 года. Полная реализация поддержки AMD64 в дереве была достигнута до первоначального выпуска оборудования, поскольку AMD предоставила несколько машин для хакатона проекта в том году. Разработчики OpenBSD взяли платформу из-за ее поддержки бита NX , что позволило легко реализовать функцию W^X .

Код для порта AMD64 OpenBSD также работает на процессорах Intel 64, которые содержат клонированное использование расширений AMD64, но поскольку Intel исключила бит таблицы страниц NX в ранних процессорах Intel 64, на этих процессорах Intel нет возможности W^X; более поздние процессоры Intel 64 добавили бит NX под названием "бит XD". Симметричная многопроцессорность (SMP) работает на порте AMD64 OpenBSD, начиная с версии 3.6 от 1 ноября 2004 года.

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "X86-64" – news · newspapers · books · scholar · JSTOR (December 2022) (Learn how and when to remove this message)

В DOS можно войти в длинный режим без расширителя DOS, ^[90] но пользователь должен вернуться в реальный режим, чтобы вызвать прерывания BIOS или DOS.

Также возможно войти в длинный режим с помощью расширителя DOS , похожего на DOS/4GW , но более сложного, поскольку в x86-64 отсутствует виртуальный режим 8086. Сама DOS об этом не знает, и не следует ожидать никаких преимуществ, если только DOS не запущена в эмуляции с соответствующим бэкэндом драйвера виртуализации, например: интерфейсом массового хранения данных.

Linux был первым ядром операционной системы, которое запускало архитектуру x86-64 в длинном режиме , начиная с версии 2.4 в 2001 году (до появления оборудования). ^{[91] [92]} Linux также обеспечивает обратную совместимость для запуска 32-битных исполняемых файлов. Это позволяет перекомпилировать программы в длинном режиме, сохраняя при этом использование 32-битных программ. Текущие дистрибутивы Linux поставляются с ядрами x86-64-native и пользовательскими пространствами . Некоторые из них, такие как Arch Linux , ^[93] SUSE , Mandriva и Debian , позволяют пользователям устанавливать набор 32-битных компонентов и библиотек при установке с 64-битного дистрибутива, что позволяет большинству существующих 32-битных приложений работать вместе с 64-битной ОС.

x32 ABI (Application Binary Interface), представленный в Linux 3.4, позволяет программам, скомпилированным для x32 ABI, работать в 64-битном режиме x86-64, используя только 32-битные указатели и поля данных. ^{[94] [95] [96]} Хотя это ограничивает программу виртуальным адресным пространством в 4 ГиБ, это также уменьшает объем памяти, занимаемый программой, и в некоторых случаях может позволить ей работать быстрее. ^{[94] [95] [96]}

64-разрядная версия Linux допускает до 128  ТиБ виртуального адресного пространства для отдельных процессов и может адресовать приблизительно 64 ТиБ физической памяти, в зависимости от ограничений процессора и системы, ^[97] или до 128 ПиБ (виртуальной) и 4 ПиБ (физической) с включенным 5-уровневым подкачиванием. ^[98]

Mac OS X 10.4.7 и более поздние версии Mac OS X 10.4 запускают 64-битные инструменты командной строки, используя библиотеки POSIX и math на 64-битных компьютерах на базе Intel, так же как все версии Mac OS X 10.4 и 10.5 запускают их на 64-битных компьютерах PowerPC. Никакие другие библиотеки или фреймворки не работают с 64-битными приложениями в Mac OS X 10.4. ^[99] Ядро и все расширения ядра являются только 32-битными.

Mac OS X 10.5 поддерживает 64-битные приложения GUI с использованием Cocoa , Quartz , OpenGL и X11 на 64-битных машинах на базе Intel, а также на 64-битных машинах PowerPC . ^[100] Все библиотеки и фреймворки, не являющиеся GUI, также поддерживают 64-битные приложения на этих платформах. Ядро и все расширения ядра являются только 32-битными.

Mac OS X 10.6 — первая версия macOS , которая поддерживает 64-битное ядро . Однако не все 64-битные компьютеры могут запускать 64-битное ядро, и не все 64-битные компьютеры, которые могут запускать 64-битное ядро, будут делать это по умолчанию. ^[101] 64-битное ядро, как и 32-битное ядро, поддерживает 32-битные приложения; оба ядра также поддерживают 64-битные приложения. 32-битные приложения имеют ограничение виртуального адресного пространства в 4 ГиБ под любым ядром. ^{[102] [103]} 64-битное ядро ​​не поддерживает 32-битные расширения ядра , а 32-битное ядро ​​не поддерживает 64-битные расширения ядра.

OS X 10.8 включает только 64-битное ядро, но продолжает поддерживать 32-битные приложения; однако она не поддерживает 32-битные расширения ядра.

macOS 10.15 включает только 64-битное ядро ​​и больше не поддерживает 32-битные приложения. Это удаление поддержки создало проблему для WineHQ (и коммерческой версии CrossOver ), поскольку ему по-прежнему необходимо иметь возможность запускать 32-битные приложения Windows. Решение, названное wine32on64 , состояло в добавлении thunks , которые переводят ЦП в режим совместимости с 32-битной версией и из него в номинально 64-битном приложении. ^{[104] [105]}

macOS использует универсальный двоичный формат для упаковки 32- и 64-битных версий кода приложений и библиотек в один файл; наиболее подходящая версия автоматически выбирается во время загрузки. В Mac OS X 10.6 универсальный двоичный формат также используется для ядра и тех расширений ядра, которые поддерживают как 32-битные, так и 64-битные ядра.

Solaris 10 и более поздние версии поддерживают архитектуру x86-64.

Для Solaris 10, как и для архитектуры SPARC , существует только один образ операционной системы, содержащий 32-битное ядро ​​и 64-битное ядро; он помечен как образ DVD-ROM "x64/x86". Поведение по умолчанию — загрузка 64-битного ядра, что позволяет запускать как 64-битные, так и существующие или новые 32-битные исполняемые файлы. 32-битное ядро ​​также можно выбрать вручную, в этом случае будут запускаться только 32-битные исполняемые файлы. Эту команду isainfoможно использовать для определения, работает ли система с 64-битным ядром.

Для Solaris 11 предусмотрено только 64-битное ядро. Однако 64-битное ядро ​​поддерживает как 32-, так и 64-битные исполняемые файлы, библиотеки и системные вызовы.

x64-версии клиента и сервера Microsoft Windows — Windows XP Professional x64 Edition и Windows Server 2003 x64 Edition — были выпущены в марте 2005 года. ^[106] Внутренне они фактически являются одной и той же сборкой (5.2.3790.1830 SP1), ^{[107] [108]} поскольку они используют одну и ту же исходную базу и двоичные файлы операционной системы, поэтому даже системные обновления выпускаются в унифицированных пакетах, во многом подобно редакциям Windows 2000 Professional и Server для x86. Windows Vista , которая также имеет много различных редакций, была выпущена в январе 2007 года. Windows 7 была выпущена в июле 2009 года. Windows Server 2008 R2 продавалась только в редакциях x64 и Itanium; более поздние версии Windows Server предлагают только редакцию x64.

Версии Windows для x64 до Windows 8.1 и Windows Server 2012 R2 предлагают следующее:

• 8 ТиБ виртуального адресного пространства на процесс, доступного как из пользовательского режима, так и из режима ядра, называемого адресным пространством пользовательского режима. Программа x64 может использовать все это, при условии соблюдения ограничений хранилища в системе и при условии, что она связана с опцией «знания больших адресов», которая присутствует по умолчанию. ^[109] Это в 4096 раз больше, чем виртуальное адресное пространство пользовательского режима по умолчанию в 2 ГиБ, предлагаемое 32-разрядной Windows. ^{[110] [111]}
• 8 ТиБ виртуального адресного пространства режима ядра для операционной системы. ^[110] Как и в случае с адресным пространством режима пользователя, это в 4096 раз больше, чем в 32-разрядных версиях Windows. Увеличенное пространство в первую очередь приносит пользу кэшу файловой системы и «кучам» режима ядра (невыгружаемый пул и выгружаемый пул). Windows использует всего 16 ТиБ из 256 ТиБ, реализованных процессорами, поскольку ранние процессоры AMD64 не имели инструкции CMPXCHG16B. ^[112]

В Windows 8.1 и Windows Server 2012 R2 виртуальные адресные пространства пользовательского режима и режима ядра были расширены до 128 ТиБ. ^[23] Эти версии Windows не будут устанавливаться на процессоры, у которых отсутствует эта CMPXCHG16Bинструкция.

Следующие дополнительные характеристики применимы ко всем версиям Windows x64:

• Возможность запуска существующих 32-разрядных приложений ( .exeпрограмм) и динамически подключаемых библиотек ( .dllбиблиотек) с использованием WoW64 , если WoW64 поддерживается в этой версии. Кроме того, 32-разрядная программа, если она была связана с опцией "large address aware", ^[109] может использовать до 4 ГиБ виртуального адресного пространства в 64-разрядной Windows вместо 2 ГиБ по умолчанию (дополнительно 3 ГиБ с /3GBопцией загрузки и опцией ссылки "large address aware"), предлагаемых 32-разрядной Windows. ^[113] В отличие от использования /3GBопции загрузки на x86, это не уменьшает виртуальное адресное пространство режима ядра, доступное операционной системе. Таким образом, 32-разрядные приложения могут извлечь выгоду из работы в x64 Windows, даже если они не перекомпилированы для x86-64.
• Как 32-, так и 64-разрядные приложения, если они не связаны с функцией «Large Address Assigned», ограничены 2 ГиБ виртуального адресного пространства.
• Возможность использования до 128 ГиБ (Windows XP/Vista), 192 ГиБ (Windows 7), 512 ГиБ (Windows 8), 1 ТиБ (Windows Server 2003), 2 ТиБ (Windows Server 2008/Windows 10), 4 ТиБ (Windows Server 2012) или 24 ТиБ (Windows Server 2016/2019) физической оперативной памяти (ОЗУ). ^[114]
• Модель данных LLP64 : в C/C++ типы «int» и «long» имеют ширину 32 бита, «long long» — 64 бита, а указатели и типы, производные от указателей, имеют ширину 64 бита.
• Драйверы устройств режима ядра должны быть 64-битными версиями; нет возможности запустить 32-битные исполняемые файлы режима ядра в 64-битной операционной системе. Драйверы устройств режима пользователя могут быть как 32-битными, так и 64-битными.
• 16-разрядные приложения Windows (Win16) и DOS не будут работать на версиях Windows x86-64 из-за удаления виртуальной подсистемы машины DOS (NTVDM), которая полагалась на возможность использования виртуального режима 8086. Виртуальный режим 8086 не может быть введен во время работы в длительном режиме.
• Полная реализация функции защиты страницы NX (No Execute). Это также реализовано в последних 32-битных версиях Windows при запуске в режиме PAE.
• Вместо дескриптора сегмента FS в версиях x86 семейства Windows NT , дескриптор сегмента GS используется для указания на две структуры, определенные операционной системой: Thread Information Block (NT_TIB) в пользовательском режиме и Processor Control Region (KPCR) в режиме ядра. Таким образом, например, в пользовательском режиме GS:0это адрес первого члена Thread Information Block. Поддержание этого соглашения упростило порт x86-64, но потребовало от AMD сохранить функцию сегментов FS и GS в длинном режиме — даже несмотря на то, что сегментированная адресация как таковая на самом деле не используется ни одной современной операционной системой. ^[110]
• В ранних отчетах утверждалось, что планировщик операционной системы не будет сохранять и восстанавливать состояние машины FPU x87 при переключении контекста потока. Наблюдаемое поведение показывает, что это не так: состояние x87 сохраняется и восстанавливается, за исключением потоков только в режиме ядра (ограничение, которое существует и в 32-разрядной версии). В последней документации, доступной от Microsoft, говорится, что инструкции x87/ MMX / 3DNow! могут использоваться в длинном режиме, но они устарели и могут вызвать проблемы совместимости в будущем. ^[113] (3DNow! больше не доступен на процессорах AMD, за исключением инструкций PREFETCHи PREFETCHW, ^[115] которые также поддерживаются на процессорах Intel, начиная с Broadwell .)
• Некоторые компоненты, такие как Jet Database Engine и Data Access Objects, не будут перенесены на 64-битные архитектуры, такие как x86-64 и IA-64. ^{[116] [117] [118]}
• Microsoft Visual Studio может компилировать собственные приложения для архитектуры x86-64, которая может работать только в 64-разрядной версии Microsoft Windows, или архитектуры IA-32 , которая может работать как 32-разрядное приложение в 32-разрядной версии Microsoft Windows или 64-разрядной версии Microsoft Windows в режиме эмуляции WoW64 . Управляемые приложения могут быть скомпилированы в режимах IA-32, x86-64 или AnyCPU. Программное обеспечение, созданное в первых двух режимах, ведет себя как их аналоги в собственном коде IA-32 или x86-64 соответственно; Однако при использовании режима AnyCPU приложения в 32-разрядных версиях Microsoft Windows работают как 32-разрядные приложения, в то время как в 64-разрядных редакциях Microsoft Windows они работают как 64-разрядное приложение.

PlayStation 4 и Xbox One используют процессоры AMD x86-64 на основе микроархитектуры Jaguar . ^{[119] [120]} Прошивки и игры написаны на коде x86-64; устаревший код x86 не задействован. PlayStation 5 и Xbox Series X/S используют процессоры AMD x86-64 на основе микроархитектуры Zen 2. ^{[121] [122]} Steam Deck использует специальный ускоренный процессор AMD x86-64 (APU) на основе микроархитектуры Zen 2. ^[123]

Поскольку AMD64 и Intel 64 в значительной степени схожи, многие программные и аппаратные продукты используют один нейтральный по отношению к поставщику термин для обозначения своей совместимости с обеими реализациями. Первоначальное обозначение AMD для этой архитектуры процессора, «x86-64», до сих пор используется для этой цели, ^[2] как и вариант «x86_64». ^{[3] [4]} Другие компании, такие как Microsoft ^[6] и Sun Microsystems / Oracle Corporation , ^[5] используют сокращение «x64» в маркетинговых материалах.

Термин IA-64 относится к процессору Itanium , и его не следует путать с x86-64, поскольку это совершенно другой набор инструкций.

Многие операционные системы и продукты, особенно те, в которых поддержка x86-64 появилась до выхода Intel на рынок, используют термин «AMD64» или «amd64» для обозначения как AMD64, так и Intel 64.

• amd64
  • Большинство систем BSD, таких как FreeBSD , MidnightBSD , NetBSD и OpenBSD, ссылаются как на AMD64, так и на Intel 64 под одним названием архитектуры «amd64».
  • Некоторые дистрибутивы Linux, такие как Debian , Ubuntu , Gentoo Linux, ссылаются как на AMD64, так и на Intel 64 под одним названием архитектуры «amd64».
  • Версии Microsoft Windows x64 используют внутри себя название AMD64 для обозначения различных компонентов, которые используют или совместимы с этой архитектурой. Например, переменной среды PROCESSOR_ARCHITECTURE присваивается значение "AMD64" в отличие от "x86" в 32-разрядных версиях, а системный каталог на установочном CD-ROM Windows x64 Edition называется "AMD64" в отличие от "i386" в 32-разрядных версиях. ^[124]
  • Команда isalist в ОС Solaris компании Sun идентифицирует системы на базе AMD64 и Intel 64 как «amd64».
  • Java Development Kit (JDK): имя «amd64» используется в именах каталогов, содержащих файлы x86-64.
• x86_64
  • Ядро Linux ^[125] и коллекция компиляторов GNU обозначают 64-битную архитектуру как «x86_64».
  • Некоторые дистрибутивы Linux, такие как Fedora , openSUSE , Arch Linux , Gentoo Linux , называют эту 64-битную архитектуру «x86_64».
  • Apple macOS называет 64-битную архитектуру «x86-64» или «x86_64», как видно из команды Терминала arch^[3] и в документации для разработчиков. ^{[2] [4]}
  • В отличие от большинства других систем BSD, DragonFly BSD называет 64-битную архитектуру «x86_64».
  • Haiku обозначает 64-битную архитектуру как «x86_64».

x86-64/AMD64 был разработан исключительно AMD. До апреля 2021 года, когда истек срок действия соответствующих патентов, AMD владела патентами на технологии, используемые в AMD64; ^{[126] [127] [128]} эти патенты должны были быть лицензированы у AMD для внедрения AMD64. Intel заключила соглашение о кросс-лицензионном соглашении с AMD, лицензировав AMD свои патенты на существующие технологии x86 и лицензировав у AMD свои патенты на технологии, используемые в x86-64. ^[129] В 2009 году AMD и Intel урегулировали несколько судебных исков и разногласий по кросс-лицензионному соглашению, продлив свои соглашения о кросс-лицензионном соглашении. ^{[130] [131] [132]}

• Универсальная инкапсулированная программная архитектура AMD (AGESA)
• Уязвимости ЦП спекулятивного выполнения

• Руководства, руководства и документы ISA для разработчиков AMD
• x86-64: Расширение архитектуры x86 до 64 бит – технический доклад архитектора AMD64 (видеоархив) и второй доклад того же докладчика (видеоархив)
• «Улучшенная защита от вирусов» от AMD
• Intel оптимизирует EM64T для полной совместимости с AMD64
• Аналитика: Intel провела обратную разработку AMD64
• Ранний отчет о различиях между Intel IA32e и AMD64
• Портирование на 64-битные системы GNU/Linux, Андреас Йегер с саммита GCC 2003. Превосходная статья, объясняющая почти все практические аспекты перехода с 32-битных на 64-битные системы.
• Архитектура Intel 64
• Intel Software Network: «64 бита»
• Обучающие материалы TurboIRC.COM, включая примеры того, как войти в защищенный и длительный режимы простым способом из DOS
• Семь шагов переноса программы на 64-битную систему
• Ограничения памяти для выпусков Windows