LIMSwiki

 Nota: "x64" e "x86-64" redirecionam para este artigo. Para o artigo sobre a implementação da Intel, veja Intel 64. Para o artigo sobre a arquitetura Intel de 64 bits em chips Itanium, veja IA-64.

AMD64 (também conhecido como x64, x86_64, x86-64 e Intel 64), em informática, é o nome genérico dado à família (arquitetura) de processadores baseados na tecnologia de 64 bits desenhado pela empresa Advanced Micro Devices (AMD), utilizada pelos processadores da AMD, da Intel, da VIA, e outros. É um superconjunto da arquitetura x86. Portanto, processadores x86-64 podem executar programas x86 (x86-80) de 32-bit ou 16-bit sem perder a velocidade ou compatibilidade, e apoiar novos programas escritos em um alargado conjunto de instruções, que inclui um espaço alocado de endereçamento de 64-bit e outras capacidades. O x86-64 é compatível com códigos de 32 bits sem afetar o desempenho destes.

O termo genérico x86-64 é as vezes encurtado para x64 como outro termo neutro para fornecedor para os processadores x86-64 de qualquer empresa.

A primeira família de processadores a suportar a arquitetura foi a linha AMD K8. Esta foi a primeira vez que qualquer empresa, fora a Intel, fez significativas adições à arquitetura x86. A Intel foi obrigada a seguir o exemplo, introduzindo modificações já no Pentium 4. A família de processadores NetBurst, inicialmente designada para IA-32, foi modificada para ser compatível com o IA-32e ou EM64T, agora chamado Intel 64, que é quase idêntico ao AMD64. A VIA Technologies, outro produtor de processadores x86, também incluiu instruções x86-64 no Isaiah, arquitetura utilizada no VIA Nano.

Posteriormente, a AMD introduziu o nome AMD64 para fins de marketing; A Intel introduziu sua nomenclatura Intel 64 logo em seguida.

A especificação x86-64 é distinta da arquitetura Intel Itanium (anteriormente IA-64), que não é compatível no nível nativo do conjunto de instrução com as arquiteturas x86 ou o x86-64.

O AMD64 (também referido pela AMD em sua literatura e documentação como “Tecnologia AMD de 64 bits” e “Arquitetura AMD x86-64”) foi criado como uma alternativa à radicalmente diferente arquitetura IA-64, projetada pela Intel e pela Hewlett Packard, que era incompatível com IA-32, a versão de 32 bits da arquitetura x86. A AMD anunciou originalmente o AMD64 em 1999^[1] com uma especificação completa disponível em agosto de 2000.^[2] Como a AMD nunca foi convidada para contribuir com a arquitetura IA-64 e qualquer tipo de licenciamento parecia improvável, a arquitetura AMD64 foi posicionada pela AMD desde o início como uma forma evolucionária de adicionar recursos de computação de 64 bits à arquitetura x86 existente enquanto oferece suporte ao código x86 legado de 32 bits, em oposição à abordagem da Intel de criar uma arquitetura de 64 bits totalmente nova e totalmente incompatível com x86 com IA-64.

O primeiro processador baseado no AMD64, o Opteron (para servidores), foi liberado em abril de 2003 e o Athlon 64 (para computadores de mesa - desktops) em setembro de 2003.

Os processadores da AMD que implementam a arquitetura AMD64 incluem Opteron, Athlon 64, Athlon 64 X2, Athlon 64 FX, Athlon II (seguido por "X2", "X3" ou "X4" para indicar o número de núcleos e modelos XLT), Turion 64, Turion 64 X2, Sempron ("Palermo" revisão E6 e todos os modelos "Manila"), Phenom, Phenom II (seguido por "X2", " X3", "X4" ou "X6" para indicar o número de núcleos), FX, Fusion/APU e Ryzen/Epyc.

A principal característica definidora do AMD64 é seu suporte para registradores de uso geral de 64 bits, operações lógicas e aritméticas inteiras de 64 bits e endereços virtuais de 64 bits. Os projetistas aproveitaram a oportunidade para fazer outras melhorias também. As mudanças mais significativas incluem:

Suporte total para números inteiros de 64 bits

Todos os registradores de propósito geral (GPRs) são expandidos de 32 bits para 64 bits, e todas as operações aritméticas e lógicas, operações de memória-para-registrador e registrador-para-memória, etc., agora são suportado diretamente para inteiros de 64 bits. Pushs e pops na pilha estão sempre em passos de oito bytes e os ponteiros têm oito bytes de largura.

Registradores adicionais

Além de aumentar o tamanho dos registradores de uso geral, o número deles é aumentado de oito (ou seja, eax, ecx, edx, ebx, esp, ebp, esi, edi), em x86-32, para dezesseis (isto é, rax, rcx, rdx, rbx, rsp, rbp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, r15). É consequentemente possível manter mais variáveis locais nos registradores do que na pilha, e constantes frequentemente acessadas; os argumentos para sub-rotinas pequenas e rápidas podem igualmente ser passados nos registradores em maior medida. Entretanto, o AMD64 ainda tem poucos registradores do que muitos conjuntos de instruções RISC comuns (que têm tipicamente 32-64 registradores) ou máquinas do tipo VLIW, tais como o IA-64 (que tem 128 registradores).

Registradores XMM (SSE) adicionais

Similarmente, o número de registradores XMM de 128 bits (usados em instruções Streaming-SIMD) é aumentado igualmente de 8 a 16.

Espaço de endereço virtual maior

A arquitetura AMD64 define um formato de endereço virtual de 64 bits, dos quais os 48 bits de ordem inferior são usados nas implementações atuais. Isso permite até 256 TB (2⁴⁸ ou 281.474.976.710.656 bytes) de espaço de endereço virtual. A definição da arquitetura permite que esse limite seja aumentado em implementações futuras para 64 bits completos, estendendo o espaço de endereço virtual para 16 EB (2⁶⁴ ou 18.446.744.073.709.551.616 bytes). Isso é comparado a apenas 4 GB (2³² ou 4.294.967.296) para o x86. Isso significa que arquivos muito grandes podem ser operados mapeando o arquivo inteiro no espaço de endereço do processo (o que geralmente é muito mais rápido do que trabalhar com chamadas de leitura/gravação de arquivo), em vez de mapear regiões do arquivo para dentro e fora do espaço de endereçamento.

Espaço de endereço físico maior

A implementação original da arquitetura AMD64 implementava endereços físicos de 40 bits e, portanto, poderia endereçar até 1 TB (2⁴⁰ ou 1.099.511.627.776 bytes) de RAM. As implementações atuais da arquitetura AMD64 (a partir da microarquitetura AMD 10h) estendem isso para endereços físicos de 48 bits e, portanto, podem endereçar até 256 (2⁴⁸ ou 281.474.976.710.656 bytes) TB de RAM. A arquitetura permite estender isso para 52 bits no futuro (limitado pelo formato de entrada da tabela de páginas); isso permitiria o endereçamento de até 4 PB (2⁵² ou 4.503.599.627.370.496 bytes) de RAM. Para comparação, os processadores x86 de 32 bits são limitados a 64 GB (2³⁶ ou 68.719.476.736 bytes) de RAM no modo Extensão de Endereço Físico (PAE) ou 4 GB (2³² ou 4.294.967.296) de RAM sem o modo PAE.

Espaço de endereço físico maior no modo legado

Ao operar no modo legado, a arquitetura AMD64 oferece suporte ao modo de Extensão de Endereço Físico (PAE), assim como a maioria dos processadores x86 atuais, mas o AMD64 estende o PAE de 36 bits para um limite arquitetônico de 52 bits de endereço físico. Qualquer implementação, portanto, permite o mesmo limite de endereço físico do modo longo.

Acesso a dados relativos ao ponteiro de instrução

As instruções podem agora referenciar os dados relativos ao ponteiro de instrução (registrador RIP). Isto torna o código independente de posição, como é usado frequentemente em bibliotecas compartilhadas e em código carregado no tempo de execução, mais eficiente.

Instruções SSE

A arquitetura AMD64 original adotou da Intel as instruções SSE e SSE2 como instruções básicas. As instruções SSE3 foram adicionadas em abril de 2005. O SSE2 substitui o conjunto de instruções de 80 bits do IEEE, com a escolha de matemática de vírgula flutuante de 32 bits ou 64 bits do IEEE. Isto fornece as operações de vírgula flutuante compatíveis com muitos outros processadores centrais modernos. As instruções SSE e SSE2 foram estendidas igualmente para operar sobre os oito registradores novos do MMX. SSE e SSE2 estão disponíveis no modo de 32 bits nos processadores x86 modernos; entretanto, se são usados em programas de 32 bits, esses programas funcionarão somente em sistemas com processadores que os suportem. Este não é um problema em programas de 64 bits, porque todos os processadores AMD64 têm SSE e SSE2, portanto, usar as instruções SSE e SSE2 em vez das instruções x87 não reduz o conjunto de máquinas em que os programas x64 podem ser exexutados. Como SSE e SSE2 são geralmente mais rápidos e duplicam a maioria das características das tradicionais instruções x87, MMX, e 3DNow!, estas últimas são redundantes sob AMD64.

Bit no-execute

O bit "NX" (63º bit da entrada da tabela de páginas) permite que o sistema operacional especifique quais páginas no espaço de endereçamento virtual podem conter códigos executáveis e quais não podem. Uma tentativa para executar código a partir de uma página etiquetada com "não executar" irá resultar em uma violação de acesso à memória, semelhante a uma tentativa de escrever para uma memória somente leitura. Isto deve tornar mais difícil, para um código malicioso, assumir o controle do sistema através de ataques de "estouro de buffer" ou "buffer não checado". A mesma funcionalidade está disponível em processadores x86 desde o 80286 como um atributo dos descritores de segmento; no entanto, isso só funciona em um segmento inteiro de uma vez. O endereçamento segmentado há muito tempo é considerado um modo obsoleto de funcionamento, e todos os sistemas operacionais nos PC atuais burlam isso, configurando todos os segmentos para um endereço base de 0 e um tamanho de 4 GB (4.294.967.296 bytes). A AMD foi a primeira fornecedora da família x86 a implementar o no-execute no modo de endereçamento linear. O recurso também está disponível no modo legado nos processadores AMD64, e nos processadores Intel x86 recentes, quando o PAE é utilizado.

Remoção das características mais velhas

Uma série de características de "programação de sistemas" da arquitectura x86 não são utilizadas nos sistemas operativos modernos e não estão disponíveis em AMD64 em modo longo (64-bit e compatibilidade). Estes incluem endereçamento segmentado (embora segmentos FS e GS são mantidos em forma vestigial, para compatibilidade com código do Windows), o mecanismo de mudança de estado de tarefa e modo 8086 virtual. Esses recursos, é claro, permanecem totalmente implementados no "modo legado", permitindo assim que esses processadores executem sistemas operacionais de 32 bits e 16 bits sem modificação. Se, em algum momento no futuro, o código de 32 bits e 16 bits com essas características não for mais usado, o suporte para elas poderá ser removido do hardware para simplificar o design do processador e economizar custos de fabricação. Esses recursos podem ser emulados no sistema operacional para preservar a compatibilidade de aplicativos legados, como no DOSBox e emuladores semelhantes.

Implementações de espaço de endereçamento canônico (os diagramas não estão em escala)

Implementação atual de 48 bits

Implementação de 57 bits

Implementação de 64 bits

Embora os endereços virtuais tenham 64 bits de largura no modo de 64 bits, as implementações actuais (e quaisquer chips conhecidos por estarem nos estágios de planeamento) não permitem que todo o espaço de endereço virtual de 16 EB (18.446.744.073.709.551.616 bytes) seja utilizado. A maioria dos sistemas operativos e aplicações não necessitará de um espaço de endereços tão grande para o futuro previsível (por exemplo, as implementações do Windows para AMD64 são apenas a povoar 16 TB (17.592.186.044.416 bytes), ou 44 bits), pelo que suportar endereços virtuais tão amplos iria simplesmente aumentar a complexidade e o custo da tradução de endereços sem qualquer benefício real. A AMD, por isso, decidiu que, nas primeiras implementações da arquitectura, apenas os 48 bits menos significativos de um endereço virtual seriam efectivamente utilizados na tradução de endereços (índice de tabela de páginas).

Além disso, a especificação da AMD exige que os 16 bits mais significativos de qualquer endereço virtual, bits 48 a 63, sejam cópias do bit 47 (de uma forma semelhante a uma extensão de assinatura). Se este requisito não for cumprido, o processador irá levantar uma exceção. Endereços conformes a esta regra são referidos como "forma canónica". Os endereços da forma canónica são executados de 0 a 00007FFF'FFFFFFFF, e a partir de FFFF8000'00000000 até FFFFFFFF'FFFFFFFF, para um total de 256 TB (281.474.976.710.656 bytes) de espaço de endereço virtual utilizável. Isto ainda é 65.536 vezes maior do que o espaço de endereçamento virtual de 4 GB de máquinas de 32 bits.

Esta característica facilita a escalabilidade posterior para endereçamento verdadeiro de 64 bits. Muitos sistemas operacionais (incluindo, mas não se limitando à família Windows NT) ocupam metade do espaço de endereçamento para si próprios (normalmente a metade superior, denominada espaço de kernel) e deixam a outra para as aplicações (espaço do utilizador). A concepção do "endereço canónico" assegura que cada implementação compatível com AMD64 tem, com efeito, duas metades de memória: a metade inferior começa em 00000000'00000000 e "cresce para cima" à medida que mais bits de endereço virtuais se tornam disponíveis, enquanto que a metade superior é "acoplada" ao topo do espaço de endereçamento e cresce para baixo. Além disso, fixar o conteúdo dos bits de endereço não utilizados evita seu uso pelo sistema operacional como sinalizadores, marcadores de privilégio, etc., o que pode se tornar problemático quando a arquitetura é de fato estendida para implementar mais bits de endereço virtual.

As primeiras versões do Windows para x64 não utilizavam nem mesmo os 256 TB completos; elas eram restritas a apenas 8 TB de espaço de usuário e 8 TB de espaço de kernel.^[3] O Windows não suportava todo o espaço de endereços de 48 bits até o Windows 8.1, que foi lançado em outubro de 2013.^[3]

O modo de endereçamento de 64 bits ("modo longo") é um superconjunto de Extensões de Endereços Físicos (PAE); devido a isto, os tamanhos de página podem ser 4 KiB (4.096 bytes) ou 2 MiB (2.097.152 bytes). Entretanto, no lugar do sistema de tabela de página de três níveis usado pelos sistemas em modo PAE, os sistemas que funcionam em modo longo usam tabela de página de quatro níveis: A Tabela de Páginas Diretas do PAE é estendida de 4 entradas para 512, e uma Tabela de Páginas Nível 4 adicional é adicionada, contendo 512 entradas em implementações de 48 bits. Em implementações que suportam endereços virtuais maiores, esta última tabela ou cresceria para acomodar entradas suficientes para descrever toda a faixa de endereços, até um máximo teórico de 33.554.432 entradas para uma implementação de 64 bits, ou seria classificada em excesso por um novo nível de mapeamento, tal como um PML5. De qualquer forma, uma hierarquia de mapeamento completa de 4 páginas KiB para todo o espaço de 48 bits levaria um pouco mais de 512 GiB de RAM (cerca de 0,196% do espaço virtual de 256 TiB).

O sistema operacional também pode limitar o espaço de endereço virtual. Os detalhes, quando aplicáveis, são fornecidos na seção "Compatibilidade do sistema operacional e características".

As implementações AMD64 atuais suportam um espaço de endereço físico de até 2⁴⁸ bytes de RAM ou 256 TB. Uma quantidade maior de RAM instalada permite que o sistema operacional mantenha mais dados e códigos pagináveis da carga de trabalho na RAM, o que pode melhorar o desempenho,^[4] embora várias cargas de trabalho tenham diferentes pontos de retornos decrescentes.^[5][6]

O limite superior de RAM que pode ser usado em um determinado sistema x86-64 depende de vários fatores e pode ser muito menor do que o implementado pelo processador. Por exemplo, em junho de 2010, não havia placas-mãe conhecidas para processadores x86-64 compatíveis com 256 TB de RAM.^{[7][8][9][10]} O sistema operacional pode colocar limites adicionais na quantidade de RAM utilizável ou suportada. Os detalhes sobre esse ponto são fornecidos na seção "Compatibilidade do sistema operacional e características" deste artigo.

A arquitetura tem dois principais modos de funcionamento: modo longo e modo legado.

O modo de operação principal pretendido da arquitetura; é uma combinação do modo nativo de 64 bits do processador e um modo de compatibilidade combinado de 32 bits e 16 bits. É usado por sistemas operacionais de 64 bits. Em um sistema operacional de 64 bits, os programas de 64 bits são executados no modo de 64 bits e os aplicativos de modo protegido de 32 e 16 bits (que não precisam usar o modo real ou o modo 8086 virtual para executar em qualquer time) executado em modo de compatibilidade. Programas em modo real e programas que usam o modo 8086 virtual a qualquer momento não podem ser executados em modo longo, a menos que sejam emulados em software.

Como o conjunto de instruções básico é o mesmo, quase não há perda de desempenho para a execução do código x86 no modo protegido. Isso é diferente do IA-64 da Intel, onde as diferenças no conjunto de instruções subjacentes significam que a execução do código de 32 bits deve ser feita na emulação de x86 (tornando o processo mais lento) ou com um núcleo x86 dedicado. No entanto, na plataforma x86-64, muitos aplicativos x86 podem se beneficiar de uma recompilação de 64 bits, devido aos registros adicionais no código de 64 bits e ao suporte ao FPU baseado em SSE2 garantido, que um compilador pode usar para otimização. No entanto, aplicativos que lidam regularmente com números inteiros maiores que 32 bits, como algoritmos criptográficos, precisarão reescrever o código que lida com números inteiros enormes para aproveitar os registradores de 64 bits.

O modo usado por sistemas operacionais de 16 bits ('modo protegido' ou 'modo real') e 32 bits. Nesse modo, o processador age como um processador x86 de 32 bits e apenas códigos de 16 e 32 bits podem ser executados. O modo legado permite um endereçamento virtual máximo de 32 bits, o que limita o espaço de endereço virtual a 4 GB. Programas de 64 bits não podem ser executados no modo legado.

O modo protegido é transformado em um submodo do modo legado. É o submodo em que os sistemas operacionais de 32 bits e os sistemas operacionais de modo protegido de 16 bits operam quando executados em uma CPU x86-64.

O modo real é o modo inicial de operação quando o processador é inicializado e é um submodo do modo legado. É compatível com os processadores originais Intel 8086 e Intel 8088. O modo real é usado principalmente pelos gerenciadores de inicialização do sistema operacional, que são exigidos pela arquitetura para configurar os detalhes da memória virtual antes da transição para modos superiores. Este modo também é usado por qualquer sistema operacional que precise se comunicar com o firmware do sistema com uma interface de estilo BIOS tradicional.

O Intel 64 é a implementação da Intel de x86-64, usada e implementada em vários processadores fabricados pela Intel.

Historicamente, a AMD desenvolveu e produziu processadores padronizados após os designs originais da Intel, mas com x86-64, os papéis foram invertidos: a Intel se viu na posição de adotar a arquitetura que a AMD havia criado como uma extensão da própria linha de processadores x86 da Intel.

O projeto da Intel foi originalmente codinomeado Yamhill (em homenagem ao rio Yamhill no Vale do Willamette, no Óregon). Após vários anos negando sua existência, a Intel anunciou no IDF de fevereiro de 2004 que o projeto estava realmente em andamento. O presidente da Intel na época, Craig Barrett, admitiu que esse era um dos segredos mais mal guardados.^[12][13]

O nome da Intel para este conjunto de instruções mudou várias vezes. O nome usado no IDF era CT (presumivelmente para Clackamas Technology, outro codinome de um rio de Oregon); dentro de semanas eles começaram a se referir a ele como IA-32e (para extensões do IA-32) e em março de 2004 revelou o nome "oficial" EM64T (Extended Memory 64 Technology). No final de 2006, a Intel começou a usar o nome Intel 64 para sua implementação, em paralelo ao uso do nome AMD64 pela AMD.^[14]

O primeiro processador da Intel a ativar a tecnologia Intel 64 foi o processador multisoquete Xeon de codinome Nocona posteriormente em 2004. Em contraste, os chips Prescott iniciais (fevereiro de 2004) não permitiam esse recurso. A Intel subsequentemente começou a vender Pentium 4s habilitados para Intel 64 usando a revisão E0 do núcleo Prescott, sendo vendido no mercado OEM como o Pentium 4, modelo F. A revisão E0 também adiciona eXecute Disable (XD) (o nome da Intel para o Bit NX) para Intel 64, e foi incluído no Xeon atual com o codinome Irwindale. O lançamento oficial da Intel do Intel 64 (sob o nome EM64T na época) em processadores de desktop convencionais foi o N0 Stepping Prescott-2M. Todas as CPUs das séries 9xx, 8xx, 6xx, 5x9, 5x6, 5x1, 3x6 e 3x1 possuem Intel 64 habilitado, assim como as CPUs Core 2, assim como futuras CPUs Intel para estações de trabalho ou servidores. O Intel 64 também está presente nos últimos membros da linha Celeron D.

O primeiro processador móvel da Intel implementando o Intel 64 é a versão Merom do processador Core 2, lançada em 27 de julho de 2006. Nenhuma das CPUs de notebook anteriores da Intel (Core Duo, Pentium M, Celeron M, Mobile Pentium 4) implementa Intel 64.

Os processadores da Intel que implementam a arquitetura Intel 64 incluem o Pentium 4 série F/série 5x1, 506 e 516, Celeron D modelos 3x1, 3x6, 355, 347, 352, 360 e 365 e todos os Celerons posteriores, todos os modelos de Xeon desde "Nocona", todos os modelos de processadores Pentium Dual-Core desde "Merom-2M", o Atom 230, 330, D410, D425, D510, D525, N450, N455, N470, N475, N550, N570, N2600 e N2800, todas as versões dos processadores Pentium D, Pentium Extreme Edition, Core 2, Core i9, Core i7, Core i5 e Core i3 e os processadores Xeon Phi da série 7200.

A VIA Technologies apresentou sua primeira implementação da arquitetura x86-64 em 2008, após cinco anos de desenvolvimento por sua divisão de CPU, Centaur Technology.^[15] Com o codinome "Isaiah", a arquitetura de 64 bits foi revelada em 24 de janeiro de 2008^{[16][17][18][19]} e lançada em 29 de maio sob a marca VIA Nano.^[20]

O processador oferece suporte a várias extensões x86 específicas da VIA projetadas para aumentar a eficiência em aparelhos de baixa potência. Espera-se que o VIA Isaiah seja duas vezes mais rápido em desempenho inteiro e quatro vezes mais rápido em desempenho de ponto flutuante do que o VIA Esther da geração anterior em uma velocidade de clock equivalente. Espera-se também que o consumo de energia esteja no mesmo nível das CPUs VIA da geração anterior, com potência de design térmico variando de 5 W a 25 W.^[21] Sendo um design completamente novo, a arquitetura Isaiah foi construída com suporte para recursos como o conjunto de instruções x86-64 e virtualização x86 que não estavam disponíveis em seus predecessores, a linha VIA C7, mantendo suas extensões de criptografia.

Em 2020, por meio de uma colaboração entre AMD, Intel, Red Hat e SUSE, foram definidos três níveis de microarquitetura acima da linha de base x86-64: x86-64-v2, x86-64-v3 e x86-64-v4.^[22][23] Esses níveis definem recursos específicos que podem ser direcionados por programadores para fornecer otimizações em tempo de compilação. Os recursos expostos por cada nível são os seguintes:^[24]

Todos os níveis incluem recursos encontrados nos níveis anteriores. As extensões do conjunto de instruções não relacionadas com a computação de uso geral, incluindo AES-NI e RDRAND, estão excluídas dos requisitos de nível.

Existem algumas diferenças entre os dois conjuntos de instruções. Os compiladores geralmente produzem binários que são compatíveis com ambos (ou seja, compatíveis com o subconjunto de X86-64 que é comum tanto para AMD64 quanto para Intel 64), tornando essas diferenças de interesse principalmente para desenvolvedores de compiladores e sistemas operacionais.

• As instruções BSF e BSR do Intel 64 agem de forma diferente quando a fonte é 0 e o tamanho do operando é 32 bits. O processador define o sinalizador zero e deixa os 32 bits superiores do destino indefinidos.
• AMD64 requer um formato de atualização de microcódigo diferente e MSRs de controle, enquanto o Intel 64 implementa a atualização de microcódigo inalterada de seus processadores somente de 32 bits.
• Intel 64 carece de alguns registradores específicos do modelo que são considerados arquitetônicos para AMD64. Isso inclui SYSCFG, TOP_MEM e TOP_MEM2.
• Intel 64 permite SYSCALL e SYSRET somente no modo IA-32e (não no modo de compatibilidade). Permite SYSENTER e SYSEXIT em ambos os modos.
• AMD64 carece de SYSENTER e SYSEXIT em ambos os submodos de modo longo.
• As ramificações próximas com o prefixo 66H (tamanho do operando) se comportam de maneira diferente. O Intel 64 limpa apenas os 32 bits principais, enquanto o AMD64 limpa os 48 bits principais.
• Os processadores AMD64 mais recentes suportam páginas de 1 GB, além de 4 KB e 2 MB.

• Os primeiros processadores AMD64 não tinham a instrução CMPXCHG16B, que é uma extensão da instrução CMPXCHG8B presente na maioria dos processadores pós-486. Semelhante ao CMPXCHG8B, o CMPXCHG16B permite operações atômicas em tipos de dados double quadword (ou oword) de 128 bits. Isso é útil para algoritmos paralelos que usam comparação e troca em dados maiores que o tamanho de um ponteiro, comum em algoritmos sem bloqueio e sem espera. Sem CMPXCHG16B, deve-se usar soluções alternativas, como uma seção crítica ou abordagens sem bloqueio alternativas.^[25]
• As primeiras CPUs AMD de 64 bits e as primeiras CPUs Intel com EM64T (desde então renomeadas para Intel 64) não tinham instruções LAHF e SAHF. A AMD apresentou as instruções com seus processadores Athlon 64, Opteron e Turion 64 revisão D em março de 2005,^[26][27][28] enquanto a Intel introduziu as instruções com o passo Pentium 4 G1 em dezembro de 2005. LAHF e SAHF são instruções de carregamento e armazenamento, respectivamente, para determinados sinalizadores de status. Essas instruções são usadas para virtualização e manipulação de condição de ponto flutuante.
• As primeiras CPUs Intel com Intel 64 também não possuem bit NX (bit no execute) da arquitetura AMD64. O bit NX marca as páginas de memória como não executáveis, permitindo proteção contra muitos tipos de códigos maliciosos.
• As primeiras implementações do Intel 64 permitiam acesso apenas a 64 GiB (68.719.476.736 bytes) de memória física, enquanto as implementações de AMD64 originais da época permitiam acesso a 1 TiB (1.099.511.627.776 bytes) de memória física.
• Implementações recentes do AMD64 agora fornecem 256 TiB (281.474.976.710.656 bytes) de espaço de endereço físico (com expansão planejada para 4 PiB [4.503.599.627.370.496 bytes]), enquanto as implementações atuais do Intel 64 permitem apenas endereçamento físico de até 256 TiB (281.471,96 bytes) de memória. As capacidades de memória física desse tamanho são apropriadas para aplicativos de grande escala (como grandes bancos de dados) e computação de alto desempenho (aplicativos orientados centralmente, aplicativos baseados na Web e computação científica).
• O AMD64 originalmente não tinha as instruções MONITOR e MWAIT, usadas pelos sistemas operacionais para lidar melhor com o recurso Hyper-threading da Intel, posteriormente para gerenciamento de threads dual core e também para entrar em estados específicos de baixo consumo de energia.
• O Intel 64 não tinha a capacidade de salvar e restaurar uma versão reduzida (e, portanto, mais rápida) do estado ponto flutuante (envolvendo as instruções FXSAVE e FXRSTOR).

Nos supercomputadores rastreados pelo TOP500, o surgimento de extensões de 64 bits para a arquitetura x86 permitiu que os processadores x86 de 64 bits da AMD e da Intel substituíssem a maioria das arquiteturas de processador RISC usadas anteriormente em tais sistemas (incluindo PA-RISC, SPARC, Alpha e outros), bem como x86 de 32 bits, embora a própria Intel inicialmente tenha tentado, sem sucesso, substituir x86 por uma nova arquitetura incompatível de 64 bits no processador Itanium.

Desde 2020, um supercomputador baseado em Fujitsu A64FX chamado Fugaku é o número um. O primeiro supercomputador baseado em ARM apareceu na lista em 2018 e, nos últimos anos, os coprocessadores de arquitetura sem CPU (GPGPU) também desempenharam um papel importante no desempenho. Os coprocessadores Xeon Phi "Knights Corner" da Intel, que implementam um subconjunto de x86-64 com algumas extensões vetoriais, também são usados, juntamente com os processadores x86-64, no supercomputador Tianhe-2.

Os seguintes sistemas operacionais e versões suportam a arquitetura x86-64 executando em modo longo:

O trabalho de infra-estrutura preliminar foi iniciado em fevereiro de 2004 para um porte em x86-64.^[30] Este desenvolvimento mais tarde estagnou. O desenvolvimento começou novamente em julho de 2007^[31] e continuou durante o Google Summer of Code 2008 e SoC 2009.^[32][33] O primeiro lançamento oficial a conter o suporte ao x86-64 foi a versão 2.4.^[34]

FreeBSD adicionou pela primeira vez o suporte ao x86-64 sob o nome "amd64" como uma arquitetura experimental no 5.1-RELEASE em junho de 2003. Foi incluído como uma arquitetura de distribuição padrão a partir do 5.2-RELEASE em janeiro de 2004. Desde então, o FreeBSD designou-a como uma plataforma Tier 1. A versão 6.0-RELEASE limpou algumas peculiaridades com a execução de executáveis x86 de 32 bits no amd64, e a maioria dos drivers funciona exatamente como em arquiteturas x86 de 32 bits. Atualmente, está sendo feito um trabalho para integrar mais completamente a interface binária de aplicação (ABI) x86 de 32 bits, da mesma maneira que a compatibilidade com ABI de 32 bits do Linux funciona atualmente.

O suporte à arquitetura x86-64 foi confirmado pela primeira vez na árvore do fonte do NetBSD em 19 de junho de 2001. A partir do NetBSD 2.0, lançado em 9 de dezembro de 2004, NetBSD/amd64 é uma porte totalmente integrado e suportado.

OpenBSD oferece suporte ao AMD64 desde o OpenBSD 3.5, lançado em 1º de maio de 2004. A implementação in-tree completa do suporte ao AMD64 foi alcançada antes do lançamento inicial do hardware devido ao empréstimo de várias máquinas pela AMD para o hackathon do projeto naquele ano. Os desenvolvedores do OpenBSD adotaram a plataforma por causa de seu suporte para o bit NX, o que permitiu uma fácil implementação do recurso W^X.

O código para a porta AMD64 do OpenBSD também é executado em processadores Intel 64 que contém o uso clonado das extensões AMD64, mas como a Intel deixou de fora o bit NX da tabela de páginas nos primeiros processadores Intel 64, não há capacidade W^X nesses processadores Intel; processadores Intel 64 posteriores adicionaram o bit NX sob o nome de "bit XD". O multiprocessamento simétrico (SMP) funciona no porte para AMD64 do OpenBSD, começando com a versão 3.6 em 1º de novembro de 2004.

É possível entrar no modo longo no DOS sem um extensor do DOS,^[35] mas o usuário deve retornar ao modo real para chamar as interrupções do BIOS ou do DOS.

Também pode ser possível entrar no modo longo com um extensor DOS semelhante ao DOS/4GW, mas mais complexo, pois o x86-64 não possui o Modo 8086 virtual. O próprio DOS não está ciente disso, e nenhum benefício deve ser esperado, a menos que execute o DOS em uma emulação com um back-end de driver de virtualização adequado, por exemplo: a interface de armazenamento em massa.

O Linux foi o primeiro kernel de sistema operacional a executar a arquitetura x86-64 em modo longo, começando com a versão 2.4 em 2001 (antes da disponibilidade do hardware físico).^[36][37] O Linux também fornece retrocompatibilidade para execução de executáveis de 32 bits. Isso permite que os programas sejam recompilados no modo longo enquanto mantêm o uso de programas de 32 bits. Várias distribuições Linux atualmente vêm com kernels e userlands nativos x86-64. Alguns, como SUSE, Mandriva e Debian GNU/Linux, permitem que os usuários instalem um conjunto de componentes e bibliotecas de 32 bits ao instalar a partir de um DVD de 64 bits, permitindo assim que a maioria dos aplicativos de 32 bits existentes sejam executados junto com o SO de 64 bits. Outras distribuições, como Fedora, Ubuntu e Arch Linux, estão disponíveis em uma versão compilada para uma arquitetura de 32 bits e outra compilada para uma arquitetura de 64 bits.

Há uma tentativa de executar o kernel no modo de compatibilidade e poder executar aplicativos de 64 bits em um kernel de 32 bits. O nome deste projeto é LINUX PAE64.^[38]

O Linux de 64 bits permite até 128 TiB (140.737.488.355.328 bytes) de espaço de endereço para processos individuais e pode endereçar aproximadamente 64 TiB (70.368.744.177.664 bytes) de memória física, sujeito às limitações do processador e do sistema.

Mac OS X v10.4.7 e versões superiores do Mac OS X v10.4 executam ferramentas de linha de comando de 64 bits usando as bibliotecas POSIX e de matemática em máquinas baseadas em Intel de 64 bits, assim como todas as versões do Mac OS X v10.4 e superior executá-los em máquinas PowerPC de 64 bits. Nenhuma outra biblioteca ou framework funciona com aplicativos de 64 bits no Mac OS X v10.4.^[39] O kernel e todas as extensões do kernel são apenas de 32 bits.

O Mac OS X v10.5 oferece suporte a aplicativos GUI de 64 bits usando Cocoa, Quartz, OpenGL e X11 em máquinas baseadas em Intel de 64 bits, bem como em máquinas PowerPC de 64 bits.^[40] Todas as bibliotecas e frameworks não GUI também oferecem suporte a aplicativos de 64 bits nessas plataformas. O kernel e todas as extensões do kernel são apenas de 32 bits.

Mac OS X v10.6 é a primeira versão do Mac OS X que suporta um kernel de 64 bits. No entanto, com seu primeiro lançamento (v10.6.0), nem todos os computadores de 64 bits são suportados atualmente. O kernel de 64 bits, como o kernel de 32 bits, suporta aplicativos de 32 bits; ambos os kernels também suportam aplicativos de 64 bits.^[41] O kernel de 64 bits não oferece suporte a extensões de kernel de 32 bits e o kernel de 32 bits não oferece suporte a extensões de kernel de 64 bits.

OS X 10.8 inclui apenas o kernel de 64 bits, mas continua a oferecer suporte a aplicativos de 32 bits; no entanto, ele não oferece suporte a extensões de kernel de 32 bits.

O macOS 10.15 inclui apenas o kernel de 64 bits e não oferece mais suporte a aplicativos de 32 bits. Essa remoção de suporte apresentou um problema para o WineHQ (e a versão comercial CrossOver), pois ele ainda precisa ser capaz de executar aplicativos do Windows de 32 bits. A solução, denominada wine32on64, foi adicionar thunks que colocam e retiram a CPU do modo de compatibilidade de 32 bits no aplicativo nominal de 64 bits.

O Mac OS X usa o formato binário universal para empacotar as versões de 32 e 64 bits do aplicativo e do código da biblioteca em um único arquivo; a versão mais apropriada é selecionada automaticamente no momento do carregamento. No Mac OS X 10.6, o formato binário universal também é usado para o kernel e para as extensões de kernel que suportam kernels de 32 bits e 64 bits.

Solaris 10 e versões posteriores suportam a arquitetura x86-64. Assim como na arquitetura SPARC, há apenas uma imagem do sistema operacional para todos os sistemas x86 de 32 bits e 64 bits; isso é rotulado como a imagem de DVD-ROM "x64/x86".

O comportamento padrão é inicializar um kernel de 64 bits, permitindo a execução de executáveis de 64 bits e existentes ou novos de 32 bits. Um kernel de 32 bits também pode ser selecionado manualmente; nesse caso, apenas executáveis de 32 bits serão executados. O comando isainfo pode ser usado para determinar se um sistema está executando um kernel de 64 bits.

As edições x86-64 do cliente e servidor Microsoft Windows—Windows XP Professional x64 Edition e Windows Server 2003 x64 Edition—foram lançadas em março de 2005. Internamente, elas são a mesma compilação (5.2.3790.1830 SP1), como eles compartilham a mesma base de origem e binários do sistema operacional, até mesmo as atualizações do sistema são lançadas em pacotes unificados, da mesma forma que as edições do Windows 2000 Professional e Server para x86. Windows Vista, que também possui muitas edições diferentes, foi lançado em janeiro de 2007. O Windows 7 foi lançado em julho de 2009. O Windows Server 2008 R2 foi vendido apenas nas edições x64 e Itanium; versões posteriores do Windows Server oferecem apenas uma edição x64.

As versões do Windows para x64 anteriores ao Windows 8.1 e Windows Server 2012 R2 oferecem o seguinte:

• 8 TiB (8.796.093.022.208 bytes) de espaço de endereço virtual do "modo de usuário" por processo. Um programa de 64 bits pode usar tudo isso, sujeito, é claro, aos limites de armazenamento do sistema. Isso representa um aumento de 4.096 vezes em relação ao espaço de endereço virtual do modo de usuário padrão de 2 GiB oferecido pelo Windows de 32 bits.
• 8 TiB (8.796.093.022.208 bytes) de espaço de endereço virtual do modo kernel para o sistema operacional. Novamente, esse é um aumento de 4.096 vezes em relação às versões de 32 bits do Windows. O aumento de espaço é benéfico principalmente para o cache do sistema de arquivos e "heaps" do modo kernel (pool não paginado e pool paginado). Os primeiros processadores AMD64 não tinham uma instrução CMPXCHG16B, então o espaço de endereço total é limitado a 16 TiB (17.592.186.044.416 bytes).^[42]

No Windows 8.1 e no Windows Server 2012 R2, os espaços de endereço virtual do modo de usuário e do modo kernel foram estendidos para 128 TB. Essas versões do Windows não serão instaladas em processadores que não possuam a instrução CMPXCHG16B.

As seguintes características adicionais se aplicam a todas as versões x64 do Windows:

• Capacidade de usar até 128 GiB (137.438.953.472 bytes; Windows XP/Vista), 192 GiB (206.158.430.208 bytes; Windows 7), 1 TiB (1.099.511.627.776 bytes; Windows Server 2003) ou 2 TiB (2.199.023.255.552 bytes; Windows Server 2008) de memória de acesso aleatório (RAM).
• Modelo de dados LLP64: os tipos "int" e "long" têm 32 bits de largura, long long tem 64bits, enquanto ponteiros e tipos derivados de ponteiros têm 64 bits de largura.
• Os drivers de dispositivo do modo kernel devem ser versões de 64 bits; não há como executar executáveis no modo kernel de 32 bits no sistema operacional de 64 bits. Os drivers de dispositivo do modo de usuário podem ser de 32 ou 64 bits.
• Capacidade de executar aplicativos existentes de 32 bits (.exe's) e bibliotecas de vínculo dinâmico (.dll's). Um programa de 32 bits, se vinculado à opção "reconhecimento de endereço grande", pode usar até 4 GiB (4.294.967.296 bytes) de espaço de endereço virtual, em comparação com o padrão de 2 GiB (2.147.483.648 bytes; opcional 3 GiB [ 3.221.225.472 bytes] com opção do boot.ini /3GB e opção de ligação "reconhecimento de endereço grande") oferecida pelo Windows de 32 bits.
• Aplicativos Windows de 16 bits (Win16) e de DOS não serão executados em versões x86-64 do Windows devido à remoção do subsistema Virtual DOS Machine (NTVDM).
• Implementação completa do recurso de proteção de página NX (No Execute). Isso também é implementado em versões recentes de 32 bits do Windows quando elas são iniciadas no modo PAE.
• Em vez do descritor de segmento FS nas versões x86 da família Windows NT, o descritor de segmento GS é usado para apontar para duas estruturas definidas pelo sistema operacional: Thread Information Block (NT_TIB) no modo de usuário e Processor Control Region (KPCR) em modo kernel. Assim, por exemplo, no modo de usuário, GS:0 é o endereço do primeiro membro do Thread Information Block. A manutenção dessa convenção tornou o porte para x86-64 mais fácil, mas exigia que a AMD retivesse a função dos segmentos FS e GS no modo longo — embora o endereçamento segmentado per se não seja realmente usado por nenhum sistema operacional moderno.^[43]
• Os primeiros relatórios afirmavam que o agendador do sistema operacional não salvaria e restauraria o estado da máquina x87 FPU nas opções de contexto da thread. O comportamento observado mostra que este não é o caso: o estado x87 é salvo e restaurado, exceto para threads somente no modo kernel (uma limitação que também existe na versão de 32 bits). A documentação mais recente disponibilizada pela Microsoft afirma que as instruções x87/MMX/3DNow! podem ser usadas em modo longo, mas são obsoletas e podem causar problemas de compatibilidade no futuro.^[44]
• Alguns componentes, como Microsoft Jet Database Engine e Data Access Objects, não serão portados para arquiteturas de 64 bits, como x86-64 e IA-64.^[45][46]
• Microsoft Visual Studio pode compilar aplicativos nativos para ter como alvo apenas a arquitetura x86-64, que será executada apenas no Microsoft Windows de 64 bits, ou a arquitetura x86, que será executada como um aplicativo de 32 bits no Microsoft Windows de 32 bits ou Microsoft Windows de 64 bits no modo de emulação WoW64. Os aplicativos gerenciados podem ser compilados nos modos x86, x86-64 ou AnyCPU. Embora os dois primeiros modos se comportem como suas contrapartes de código nativo x86 ou x86-64, respectivamente, ao usar o modo AnyCPU, os aplicativos são executados como um aplicativo de 32 bits no Microsoft Windows de 32 bits ou como um aplicativo de 64 bits no Microsoft Windows de 64 bits.

Tanto o PlayStation 4 quanto o Xbox One, e todas as variantes desses consoles, incorporam processadores AMD x86-64, baseados na microarquitetura Jaguar. Firmware e jogos são escritos em código x86-64; nenhum código legado x86 está envolvido.

Suas próximas gerações, o PlayStation 5 e o Xbox Series X e Series S, respectivamente, também incorporam processadores AMD x86-64, baseados na microarquitetura Zen 2.

Apesar de ser considerado um PC, o Steam Deck usa uma unidade de processamento acelerado (APU) AMD x86-64 personalizada, baseada na microarquitetura Zen 2.

Como AMD64 e Intel 64 são substancialmente semelhantes, muitos produtos de software e de hardware usam um termo neutro para fornecedor para indicar sua compatibilidade com ambas as implementações. A designação original da AMD para esta arquitetura de processador, "x86-64", ainda é usada às vezes para esta finalidade, assim como a variante "x86_64".^[47] Outras empresas, como Microsoft e Sun Microsystems/Oracle Corporation, usam a contração "x64" em material de marketing.

O termo IA-64 refere-se ao processador Itanium e não deve ser confundido com o X86-64, pois é um conjunto de instruções completamente diferente.

Muitos sistemas operacionais e produtos, especialmente aqueles que introduziram o suporte ao x86-64 antes da entrada da Intel no mercado, usam o termo "AMD64" ou "amd64" para se referir tanto ao AMD64 quanto ao Intel 64.

• amd64
  • A maioria dos sistemas BSD, como FreeBSD, MidnightBSD, NetBSD e OpenBSD, referem-se tanto ao AMD64 quanto ao Intel 64 sob o nome de arquitetura "amd64".
  • Algumas distribuições Linux, como Debian, Ubuntu, e Gentoo Linux, se referem tanto ao AMD64 quanto ao Intel 64 sob o nome de arquitetura "amd64".
  • Microsoft Windows: As versões x86-64 do Windows usam internamente o apelido AMD64 para designar vários componentes que usam ou são compatíveis com essa arquitetura. Por exemplo, o diretório do sistema em um CD-ROM de instalação do Windows x64 Edition é denominada "AMD64", em contraste com "i386" nas versões de 32 bits.
  • Solaris: O comando "isalist" no sistema operacional Solaris da Sun identifica os sistemas baseados em AMD64 e em Intel 64 como "amd64".
  • Java Development Kit (JDK): O nome "amd64" é usado em nomes de diretório contendo arquivos x86-64.
• x86_64
  • O kernel Linux e GNU Compiler Collection referem-se à arquitetura de 64 bits como "x86_64".
  • Algumas distribuições Linux, como Fedora, openSUSE, Arch Linux e Gentoo Linux, se referem a essa arquitetura de 64 bits como "x86_64".
  • macOS: A Apple se refere à arquitetura de 64 bits como "x86_64", conforme observado no comando arch do Terminal e na documentação do desenvolvedor.^[48]
  • Rompendo com a maioria dos outros sistemas BSD, o DragonFly BSD se refere à arquitetura de 64 bits como "x86_64".
  • Haiku: refere-se à arquitetura de 64 bits como "x86_64".
  • T2 SDE refere-se a AMD64 e Intel 64 sob o nome de arquitetura "x86-64", nos diretórios de código-fonte e metainformações do pacote.

A AMD licenciou seu projeto x86-64 à Intel, onde é introduzido no mercado sob o nome Intel 64 (anteriormente EM64T). O projeto da AMD substituiu tentativas anteriores feitas pela Intel de projetar suas próprias extensões do x86-64, que tinham sido referidas como IA-32e. Como a Intel licencia à AMD o direito de usar a arquitetura x86 original (em cima do que o x86-64 é baseado), estas companhias rivais agora dependem uma da outra para o desenvolvimento do processador de 64 bits. Isto levou a um exemplo de destruição mútua assegurada caso uma das empresas se recuse a renovar a licença.^[49] Caso tal cenário ocorra, a AMD não estaria mais autorizada a produzir nenhum processador x86, e a Intel não estaria mais autorizada a produzir processadores x86-64, forçando-a a voltar para a arquitetura x86 de 32 bits. No entanto, o acordo^[50] prevê que, se uma das partes violar o acordo, ela perde todos os direitos sobre a tecnologia da outra parte, enquanto a outra parte recebe direitos perpétuos sobre toda a tecnologia licenciada. Os únicos processadores Intel x86 atuais de 32 bits são versões do processador Intel Atom de baixo consumo.

Em 2009, a AMD e a Intel resolveram várias ações judiciais e divergências de licenciamento cruzado, estendendo seus acordos de licenciamento cruzado para o futuro previsível e resolvendo várias reclamações antitruste.^[51]

Referências

• «x86-64 technology white paper». Advanced Micro Devices, Inc. Consultado em 24 de dezembro de 2006. Arquivado do original em 13 de novembro de 2006 
• «AMD eighth-generation processor architecture». Advanced Micro Devices, Inc. Consultado em 24 de dezembro de 2006. Arquivado do original em 13 de novembro de 2006 
• «AMD64 architecture programmer's manual volume 1: application programming». Consultado em 24 de dezembro de 2006. Arquivado do original em 19 de outubro de 2006 
• «AMD64 architecture programmer's manual volume 2: system programming». Consultado em 24 de dezembro de 2006. Arquivado do original em 19 de outubro de 2006