AMD64

Origem: Wikipédia, a enciclopédia livre.
Disambig grey.svg 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 64-bit formalmente chamada de IA-64, veja IA-64.
Opteron, o primeiro microprocessador a introduzir as extensões x86-64 em 2003

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.

AMD64[editar | editar código-fonte]

Logo do AMD64

O conjunto de instruções AMD64 é implementado nos processadores AMD Opteron, Athlon 64, Athlon 64 FX, Athlon 64 X2, Athlon II, Athlon X2, Turion 64, Turion 64 X2, Sempron mais recentes, Phenom, Phenom II, FX e Fusion.

História[editar | editar código-fonte]

O AMD64 foi criado como uma alternativa à radicalmente diferente arquitetura IA-64, projetada pela Intel e pela Hewlett Packard. Anunciado originalmente em 1999[1] com uma especificação completa em agosto de 2000, [2] 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, em oposição à abordagem da Intel de criar uma arquitetura de 64 bits inteiramente nova com o 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.

Características[editar | editar código-fonte]

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, EBX, ECX, EDX, EBP, ESP, ESI, EDI), em x86-32, para dezesseis (isto é, RAX, RBX, RCX, RDX, RBP, RSP, 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 adicionais do XMM: Similarmente, o número de registradores de 128 bit do XMM (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 (248 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 (264 ou 18.446.744.073.709.551.616 bytes). Isso é comparado a apenas 4 GB (232 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 (240 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 (248 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 (252 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 (236 ou 68.719.476.736 bytes) de RAM no modo Extensão de Endereço Físico (PAE) ou 4 GB (232 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.

Detalhes do espaço de endereço virtual[editar | editar código-fonte]

Endereços de forma canônica[editar | editar código-fonte]

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). No entanto, os bits 48 a 63 de qualquer endereço virtual deve ser cópias do bit 47 (de uma forma semelhante a uma extensão de assinatura), ou 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.

Esta "peculiaridade" permite uma importante característica para uma 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 52, 56, 60 e 64 bits.

Estrutura da tabela de páginas[editar | editar código-fonte]

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).

Limites do sistema operacional[editar | editar código-fonte]

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".

Detalhes do espaço de endereço físico[editar | editar código-fonte]

As implementações AMD64 atuais suportam um espaço de endereço físico de até 248 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,[3] embora várias cargas de trabalho tenham diferentes pontos de retornos decrescentes.[4][5]

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.[6][7][8][9] 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.

Modos de operação[editar | editar código-fonte]

Modo de funcionamento Sistema operacional necessário Recompilação de aplicativo necessária Tamanho do endereço padrão Tamanho padrão do operando Extensões de registrador Largura típica do GPR
Modo longo Modo de 64 bits SO com suporte a 64 bits, ou bootloader para SO de 64 bits Sim 64 32 Sim 64
Modo de compatibilidade Não 32 32 Não 32
16 16 16
Modo legado Modo protegido SO legado de 16 bits ou de 32 bits; ou bootloader para SO de 16, 32, ou 64 bits Não 32 32 Não 32
16 16 16
Modo 8086 virtual SO legado de 16 bits ou de 32 bits 16 16 16
Modo real SO legado de 16 bits; ou bootloader para SO de 16, 32, ou 64 bits

A arquitetura tem dois principais modos de funcionamento:

Modo longo[editar | editar código-fonte]

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.

Modo legado[editar | editar código-fonte]

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.

Implementações x64 da AMD[editar | editar código-fonte]

Os seguintes processadores implementam a arquitetura AMD64:

  • AMD Athlon 64
  • AMD Athlon 64 X2
  • AMD Athlon 64 FX
  • AMD Opteron
  • AMD Turion 64
  • AMD Turion 64 X2
  • AMD Sempron ("Palermo" stepping E6 e todos os modelos "Manila")
  • AMD Phenom, muitas vezes seguido por X3 ou X4, para indicar o número de núcleos.
  • AMD Phenom II, (45 nm) freqüentemente seguidos por X2, X3, X4 ou X6 para indicar o número de núcleos.
  • AMD FX Series, em versões X4 X6 ou X8, utilizado em socket AM3+ em placas-mãe DDR3
  • AMD Fusion
  • AMD Ryzen, lançado em 2017 para placas-mãe DDR4 em versões de 4, 6 e 8 núcleos
  • AMD EPYC

Intel 64[editar | editar código-fonte]

O Intel 64 é a implementação da Intel de x86-64. É usado nas versões mais recentes dos processadores Pentium 4, Celeron D, Xeon e Pentium Dual-Core, Atom D510, N450, N550, N2600 e N2800 e em todas as versões dos processadores Pentium Extreme Edition, Core 2, Core i7, Core i5 e Core i3.

História do Intel 64[editar | editar código-fonte]

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.[10][11]

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.[12]

Implementações de Intel 64[editar | editar código-fonte]

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 seguintes processadores implementam a arquitetura Intel 64:

Implementação da VIA de x86-64[editar | editar código-fonte]

O VIA Nano (anteriormente codinomeado VIA Isaiah) é uma CPU de 64 bits para computadores pessoais. O VIA Nano foi lançado pela VIA Technologies em 2008 após cinco anos de desenvolvimento[13] por sua divisão de CPU, Centaur Technology. Essa nova arquitetura Isaiah 64-bit foi projetada do zero, revelada em 24 de janeiro de 2008[14][15][16][17] e lançada em 29 de maio, incluindo variantes de baixa voltagem e a marca Nano.[18] 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.[19] 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.

Níveis de microarquitetura[editar | editar código-fonte]

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.[20][21] 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:[22]

Níveis de microarquitetura da CPU
Nível Recursos da CPU Exemplo de instrução
x86-64 (também x86-64-v1)
(linha de base: todas as CPUs x86-64)
CMOV cmov
CX8 cmpxchg8b
FPU fld
FXSR fxsave
MMX emms
OSFXSR fxsave
SCE syscall
SSE cvtss2si
SSE2 cvtpi2pd
x86-64-v2
(por volta de 2009: Nehalem e Jaguar)

Também:

  • Emulação do QEMU
  • Atom Silvermont (2013)
  • VIA Nano e Eden "C" (2015)
CMPXCHG16B cmpxchg16b
LAHF-SAHF lahf
POPCNT popcnt
SSE3 addsubpd
SSE4_1 blendpd
SSE4_2 pcmpestri
SSSE3 phaddd
x86-64-v3
(por volta de 2015: Haswell e Excavator)

Também:

  • Atom Gracemont (2021)
AVX vzeroall
AVX2 vpermd
BMI1 andn
BMI2 bzhi
F16C vcvtph2ps
FMA vfmadd132pd
LZCNT lzcnt
MOVBE movbe
OSXSAVE xgetbv
x86-64-v4
(Subconjunto de uso geral do AVX-512)
AVX512F kmovw
AVX512BW vdbpsadbw
AVX512CD vplzcntd
AVX512DQ vpmullq
AVX512VL n/a

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.

Diferenças entre AMD64 e Intel 64[editar | editar código-fonte]

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.

Implementações recentes[editar | editar código-fonte]

  • 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.

Implementações mais antigas[editar | editar código-fonte]

  • 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.[23]
  • 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,[24][25][26] 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).

Compatibilidade do sistema operacional e características[editar | editar código-fonte]

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

BSD[editar | editar código-fonte]

DragonFly BSD[editar | editar código-fonte]

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

FreeBSD[editar | editar código-fonte]

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.

NetBSD[editar | editar código-fonte]

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[editar | editar código-fonte]

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.

DOS[editar | editar código-fonte]

É possível entrar no modo longo no DOS sem um extensor do DOS,[32] 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.

Linux[editar | editar código-fonte]

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).[33][34] 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.[35]

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[editar | editar código-fonte]

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.[36] 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.

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.[37] 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.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.[38] O kernel e todas as extensões do kernel são apenas de 32 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[editar | editar código-fonte]

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.

Windows[editar | editar código-fonte]

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 para x86-64 possui as seguintes características:

  • 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).[39]
  • 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.[40]
  • 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.[41]
  • 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.[42][43]
  • 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.

Convenções de nomenclatura da indústria[editar | editar código-fonte]

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".[44] Outras empresas, como Microsoft e Sun Microsystems, 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.

  • Sistemas BSD como FreeBSD, MidnightBSD, NetBSD e OpenBSD referem-se tanto ao AMD64 quanto ao Intel 64 sob o nome de arquitetura "amd64".
  • O kernel Linux e DragonFly BSD referem-se à arquitetura de 64 bits como "x86_64".
  • Debian, Ubuntu, e Gentoo se referem tanto ao AMD64 quanto ao Intel 64 sob o nome de arquitetura "amd64".
  • O GNU Compiler Collection, Fedora PackageKit, openSUSE, e Arch Linux se referem a essa arquitetura de 64 bits como "x86_64".
  • Haiku: refere-se à arquitetura de 64 bits como "x86_64".
  • Java Development Kit (JDK): O nome "amd64" é usado em nomes de diretório contendo arquivos x86-64.
  • Mac OS X: A Apple se refere à arquitetura de 64 bits como "x86_64", conforme observado no comando arch do Terminal e na documentação do desenvolvedor.[45]
  • 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".
  • 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.

Problemas legais[editar | editar código-fonte]

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.[46] 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[47] 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.[48]

Referências

  1. «AMD Discloses New Technologies At Microporcessor Forum» (Nota de imprensa). AMD. 5 de outubro de 1999. Consultado em 9 de novembro de 2010. Arquivado do original em 8 de março de 2012 
  2. «AMD Releases x86-64 Architectural Specification; Enables Market Driven Migration to 64-Bit Computing» (Nota de imprensa). AMD. 10 de agosto de 2000. Consultado em 9 de novembro de 2010. Arquivado do original em 8 de março de 2012 
  3. Jeff Tyson (15 de janeiro de 2004). «How Virtual Memory Works». howstuffworks. Consultado em 7 de junho de 2010. The read/write speed of a hard drive is much slower than RAM, and the technology of a hard drive is not geared toward accessing small pieces of data at a time. If your system has to rely too heavily on virtual memory, you will notice a significant performance drop. The key is to have enough RAM to handle everything you tend to work on simultaneously. 
  4. Jason Dunn (3 de setembro de 2003). «Computer RAM: A Crucial Component in Video Editing». Microsoft Corporation. Consultado em 9 de junho de 2010. There's a point of diminishing returns where adding more RAM won't give you better system performance. 
  5. «Understanding Memory Configurations and Exchange Performance». Microsoft Corporation. 3 de setembro de 2003. There is, however, a point of diminishing returns at which adding memory to the server may not be justifiable based on price and performance. 
  6. «Opteron 6100 Series Motherboards». Supermicro Corporation. Consultado em 22 de junho de 2010 
  7. «Supermicro Xeon Solutions». Supermicro Corporation. Consultado em 20 de junho de 2010 
  8. «Opteron 8000 Series Motherboards». Supermicro Corporation. Consultado em 20 de junho de 2010 
  9. «Tyan Product Matrix». MiTEC International Corporation. Consultado em 21 de junho de 2010 
  10. «Craig Barrett confirms 64 bit address extensions for Xeon. And Prescott». The Inquirer. Arquivado do original em 10 de setembro de 2007 
  11. «A Roundup of 64-Bit Computing». internetnews.com. Arquivado do original em 5 de maio de 2009 
  12. «Intel 64 Architecture». Intel. Consultado em 29 de junho de 2007 
  13. «VIA to launch new processor architecture in 1Q08». DigiTimes. Consultado em 25 de julho de 2007. (pede subscrição (ajuda)) 
  14. Stokes, Jon (23 de janeiro de 2008). «Isaiah revealed: VIA's new low-power architecture». Ars Technica. Consultado em 24 de janeiro de 2008 
  15. Bennett, Kyle (24 de janeiro de 2008). «VIA's New Centaur Designed Isaiah CPU Architecture». [H]ard|OCP. Consultado em 24 de janeiro de 2008 
  16. «Via launches 64-bit architecture». LinuxDevices.com. 23 de janeiro de 2008. Consultado em 24 de janeiro de 2008 
  17. Wasson, Scott (24 de janeiro de 2008). «A look at VIA's next-gen Isaiah x86 CPU architecture». The Tech Report. Consultado em 24 de janeiro de 2008 
  18. «VIA Launches VIA Nano Processor Family» (Nota de imprensa). VIA. 29 de maio de 2008. Consultado em 29 de maio de 2008 
  19. «VIA Isaiah Architecture Introduction» (PDF). VIA. 23 de janeiro de 2008. Consultado em 28 de maio de 2008 
  20. Weimer, Florian (10 de julho de 2020). «New x86-64 micro-architecture levels». llvm-dev (Lista de grupo de correio). Consultado em 11 de março de 2021. Cópia arquivada em 14 de abril de 2021 
  21. Weimer, Florian (5 de janeiro de 2021). «Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level». Red Hat developer blog. Consultado em 22 de março de 2022 
  22. «System V Application Binary Interface Low Level System Information». x86-64 psABI repo. 29 de janeiro de 2021. Consultado em 11 de março de 2021. Cópia arquivada em 2 de fevereiro de 2021 – via GitLab 
  23. «Practical Lock-Free and Wait-Free LL/SC/VL Implementations Using 64-Bit CAS» (PDF). Arquivado do original (PDF) em 1 de fevereiro de 2005 
  24. «Revision Guide for AMD Athlon 64 and AMD Opteron Processors» (PDF). AMD 
  25. «AMD Turion 64 pictured up and running». The Inquirer 
  26. «Athlon 64 revision E won't work on some Nforce 3/4 boards». The Inquirer 
  27. «cvs commit: src/sys/amd64/amd64 genassym.c src/sys/amd64/include asm.h atomic.h bootinfo.h coredump.h cpufunc.h elf.h endian.h exec.h float.h fpu.h frame.h globaldata.h ieeefp.h limits.h lock.h md_var.h param.h pcb.h pcb_ext.h pmap.h proc.h profile.h psl.h ...». Consultado em 3 de maio de 2009 
  28. «AMD64 port». Consultado em 3 de maio de 2009 
  29. «DragonFlyBSD: GoogleSoC2008». Consultado em 3 de maio de 2009 
  30. «Summer of Code accepted students». Consultado em 3 de maio de 2009 
  31. «DragonFlyBSD: release24». Consultado em 3 de maio de 2009 
  32. Tutorial for entering protected and long mode from DOS
  33. Andi Kleen (26 de junho de 2001), Porting Linux to x86-64, Status: The kernel, compiler, tool chain work. The kernel boots and work on simulator and is used for porting of userland and running programs 
  34. Andi Kleen, Andi Kleen's Page, This was the original paper describing the Linux x86-64 kernel port back when x86-64 was only available on simulators. 
  35. «LinuxPAE64» 
  36. http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/5
  37. Apple - Mac OS X Leopard - Technology - 64 bit
  38. Apple - Mac OS X Xcode 2.4 Release Notes: Compiler Tools
  39. «Behind Windows x86-64's 44-bit Virtual Memory Addressing Limit». Consultado em 2 de julho de 2009 
  40. «Everything You Need To Know To Start Programming 64-Bit Windows Systems». On x86-64 versions of Windows, the FS register has been replaced by the GS register. 
  41. «64-bit programming for Game Developers». The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit modes. 
  42. Microsoft Developer Network - General Porting Guidelines (64-bit Windows Programming)
  43. Microsoft Developer Network - Data Access Road Map
  44. Kevin Van Vechten (9 de agosto de 2006). «re: Intel XNU bug report». Darwin-dev mailing list. Apple Computer. Consultado em 5 de outubro de 2006. The kernel and developer tools have standardized on "x86_64" for the name of the Mach-O architecture 
  45. «Mac OS X Manual Page For arch(1)». Arquivado do original em 10 de agosto de 2009 
  46. «AMD plays antitrust poker for Intel's X86 licence». Incisive Media Limited. 3 de fevereiro de 2009. Consultado em 26 de fevereiro de 2009. Arquivado do original em 28 de fevereiro de 2009 
  47. «Patent Cross License Agreement Between AMD and Intel». 1 de janeiro de 2001. Consultado em 23 de agosto de 2009. Arquivado do original em 29 de abril de 2009 
  48. «AMD Intel Settlement Agreement». Cópia arquivada em 30 de março de 2022 

Ligações externas[editar | editar código-fonte]