Por que os sistemas x86-64 têm apenas um espaço de endereço virtual de 48 bits?

97

Em um livro, li o seguinte:

Os processadores de 32 bits têm 2 ^ 32 endereços possíveis, enquanto os processadores atuais de 64 bits têm um espaço de endereço de 48 bits

Minha expectativa era que, se for um processador de 64 bits, o espaço de endereço também deveria ser 2 ^ 64.

Então, eu queria saber qual é o motivo dessa limitação?

— er4z0r
fonte

11

O livro deve ter falado especificamente sobre a implementação atual da arquitetura AMD64 (x86-64). Apenas os 48 bits de ordem inferior são usados. No entanto, isso não é uma limitação de hardware - todos os 64 bits estão disponíveis.

— Cody Gray

7

É sempre uma boa ideia identificar o livro.

— Henk Holterman

1

Eu estou supondo que as linhas de endereço físico não estão livres (você precisa de pelo menos 16 pinos de CPU extras). E ainda não conheço nenhum hardware que possa preencher um espaço de 48 bits com chips de RAM físicos no mesmo processador. Quando isso se tornar viável, tenho certeza que a AMD adicionará os 16 pinos ausentes :)

— Torp

7

mesmo, The 32-bit processors have 2^32 possible addressesnão é necessariamente verdade, pode existir uma CPU de 32 bits com apenas 24 "pinos" para endereçar a memória. Por exemplo, 68EC020 (versão 68020 mais barata) é uma CPU de 32 bits, mas com 24 bits para endereçamento de memória.

— ShinTakezou de

21

Há um problema muito real com o endereçamento físico de 64 bits, o tamanho da página da memória virtual é muito pequeno. O que resulta em enormes diretórios de página e descargas de cache TLB extremamente caras em cada troca de contexto. Mudar de páginas de 4 MB para 4 MB é uma opção, mas muito incompatível com os sistemas operacionais atuais.

— Hans Passant

134

Porque isso é tudo o que é necessário. 48 bits fornecem um espaço de endereço de 256 terabytes. Isso é muito. Você não verá um sistema que precisa de mais do que isso tão cedo.

Portanto, os fabricantes de CPU escolheram um atalho. Eles usam um conjunto de instruções que permite um espaço de endereço completo de 64 bits, mas as CPUs atuais usam apenas os 48 bits inferiores. A alternativa era desperdiçar transistores ao lidar com um espaço de endereço maior, que não seria necessário por muitos anos.

Portanto, quando chegarmos perto do limite de 48 bits, é apenas uma questão de liberar CPUs que controlam o espaço de endereço completo, mas não exigirá nenhuma alteração no conjunto de instruções e não quebrará a compatibilidade.

— Jalf
fonte

118

640kb é o suficiente para qualquer pessoa.

7

Você ainda está executando um sistema 8088, bdares?

— Joe

23

@bdares: Má analogia. O conjunto de instruções do arco 8088/8086 possui um limite de 640k embutido. Apenas fazendo um novo ISA (386) foi possível quebrar a barreira. Por outro lado, x86_64 oferece suporte a todos os 64 bits no ISA. É apenas o hardware da geração atual que não pode fazer uso de todos eles ...

— R .. GitHub PARE DE AJUDAR O ICE

16

@R. Na verdade, a limitação da CPU era de um megabyte. O IBM PC designou uma seção para periféricos mapeados na memória, BIOS, etc. Alguns outros designs de 8088/8086 (Zenith Z100, se a memória não servir) designaram menos para periféricos e outros, e correspondentemente mais para programas de aplicativos.

— Jerry Coffin

25

lwn.net/SubscriberLink/655437/9a48cd3e7a8cbe8a <- três anos após esta resposta, já estamos atingindo esses limites :) A máquina HP terá 320 TB de memória e eles não podem fornecê-la como um espaço de endereço plano por causa dos 48 limitação de endereçamento de bits.

— agam

18

Qualquer resposta referente ao tamanho do barramento e memória física está um pouco equivocada, já que a pergunta do OP era sobre o espaço de endereço virtual e não o espaço de endereço físico . Por exemplo, o limite supostamente análogo em alguns 386's era um limite na memória física que eles podiam usar, não o espaço de endereço virtual, que sempre era de 32 bits completos. Em princípio, você poderia usar 64 bits completos de espaço de endereço virtual, mesmo com apenas alguns MB de memória física; é claro que você pode fazer isso trocando ou para tarefas especializadas onde deseja mapear a mesma página na maioria dos endereços (por exemplo, certas operações de dados esparsos).

Acho que a verdadeira resposta é que a AMD estava sendo barata e esperava que ninguém se importasse agora, mas não tenho referências para citar.

— R .. GitHub PARAR DE AJUDAR O GELO
fonte

14

"Ser barato" Acho que você quer dizer não adicionar pinos que nunca serão usados, não ocupar espaço no chip para transistores que não serão usados e usar o espaço liberado para tornar as instruções existentes mais rápidas? Se isso está sendo barato, estou dentro!

— Olof Forshell

O 80386 permite 2 * 4096 seletores, cada um contendo até 4 GB de memória (total de 32 TB). O 80286 permitia 2 * 4096 seletores, cada um contendo até 64 KB (1 GB).

— Olof Forshell

Os hacks segmentados não lineares não contam como espaço de endereço no meu livro. Não há como o software portátil fazer qualquer uso deles.

— R .. GitHub PARAR DE AJUDAR O ICE

@R .. - Achei que a definição de software portátil é que ele pode . :-) Por exemplo, C ++ proíbe comparar ponteiros em matrizes diferentes para que possam estar em segmentos separados de 4 GB.

— Bo Persson

Se sua compilação realmente gera grandes ponteiros e carrega um registrador de segmento para cada desreferência de memória, então sim. Mas na realidade isso é terrivelmente lento e, em vez disso, todos usaram pequenos modelos de memória e __far(ou pior ainda, FAR/ far!) Ponteiros ...

— R .. GitHub PARE DE AJUDAR O ICE

10

Leia a seção de limitações do artigo da wikipedia :

Um PC não pode conter 4 petabytes de memória (devido ao tamanho dos chips de memória atuais, se nada mais), mas a AMD imaginou grandes servidores, clusters de memória compartilhada e outros usos de espaço de endereço físico que podem se aproximar disso em um futuro previsível, e os 52 endereço físico de bits oferece amplo espaço para expansão, sem incorrer no custo de implementação de endereços físicos de 64 bits

Ou seja, não faz sentido implementar o endereçamento de 64 bits completo neste ponto, porque não podemos construir um sistema que poderia utilizar esse espaço de endereço por completo - então escolhemos algo que seja prático para os sistemas de hoje (e de amanhã).

— Damien_The_Unbeliever
fonte

De onde vem o 4 nos 4 petabytes? Se estamos falando de 64 linhas de endereço, devemos terminar com o quadrado do espaço de endereço possibilitado por 32 linhas de endereço, que é de 4 gigabytes. Quadrado isso e devemos ter 16, não 4 petabytes. Estou esquecendo de algo?

— Olof Forshell

1

Vem do limite físico atual (52 bits) - o ponto é que não podemos colocar RAM suficiente em um PC para suportar esse intervalo restrito, muito menos o que seria necessário para um espaço de endereço de 64 bits completo.

— Damien_The_Unbeliever

9

A largura de registro / operação nativa interna não precisa ser refletida na largura do barramento de endereço externo.

Digamos que você tenha um processador de 64 bits que só precisa acessar 1 megabyte de RAM. Um barramento de endereço de 20 bits é tudo o que é necessário. Por que se preocupar com o custo e a complexidade do hardware de todos os pinos extras que você não usará?

O Motorola 68000 era assim; 32 bits internamente, mas com um barramento de endereço de 23 bits (e um barramento de dados de 16 bits). A CPU podia acessar 16 megabytes de RAM e, para carregar o tipo de dados nativo (32 bits), precisava de dois acessos à memória (cada um contendo 16 bits de dados).

1

mas 68000 é considerado como uma CPU de "16/32 bits", não uma CPU de 32 bits "cheia", portanto, pode-se dizer que ainda tem um pé no passado de 16 bits; Eu escolhi o 68020 como exemplo, já que sua versão 68EC020 de baixo custo tem 24 bits apenas para endereços, embora o 68020 seja uma CPU "completa" de 32 bits ... +1 ter considerado esta família de processadores maravilhosa!

— ShinTakezou de

@ShinTakezou: honestamente, o 80386SX era uma CPU de 16 bits (porque tinha um espaço de endereço como o 80286) ou era de 32 bits (porque tinha a arquitetura interna de um 80386DX)? Alguém poderia dizer como você, mas outro (este) diz "interno é o que conta" - e você pode me citar sobre isso.

— Olof Forshell

@Olof acho que, no contexto da "memória" (que é o mundo externo), externo é o que conta, então 68000 é uma CPU de 16 bits (precisando de 2 "passos" para ler dados de 32 bits): D

— ShinTakezou

@ShinTakezou: o contexto da memória, até mesmo os caches, é sempre externo à própria cpu, embora sejam extremamente acoplados nos processadores modernos. O 8088 era internamente igual ao 8086, embora tivesse oito linhas de barramento de dados contra dezesseis do 8086. Não vejo o que você aparentemente vê como óbvio, que o 8088 deveria ser classificado no mesmo grupo que o Z80, 8080, 8085 etc. A questão da largura do barramento de dados parece trivial nesse contexto

— Olof Forshell

Eu não sou um especialista em tal assunto, então não tenho nada óbvio para mim. Eu queria apenas notar a necessidade de um corte mais nítido com o passado, onde se poderia pensar que 68000 ainda é um processador dos "velhos tempos", então que pode parecer "natural" que seu espaço de endereço seja limitado a menos de 32 bits; enquanto o 68020 pode 32 bits, de modo que a existência do 68EC020 com seu limite deixa claro que é uma escolha não devido ao "limite disso ( ou este) tempo ", mas para outra consideração (como torná-lo mais barato se não houver vantagem real em ter 64 pinos), que é mais ou menos o argumento desta resposta.

— ShinTakezou de

7

Há uma razão mais grave do que apenas salvar transistores no caminho de endereço da CPU: se você aumentar o tamanho do espaço de endereço, você precisa aumentar o tamanho da página, aumentar o tamanho das tabelas de página ou ter uma estrutura de tabela de página mais profunda (que é mais níveis de tabelas de tradução). Todas essas coisas aumentam o custo de uma falha de TLB, o que prejudica o desempenho.

— Brendan
fonte

1

A Intel está propondo um esquema de paginação de 5 níveis para estender dos atuais 48 bits para 57 bits. (Mesmos 9 bits por nível / 4k páginas que as tabelas de páginas x86-64 atuais). Usar 10 ou 11 bits por nível exigiria a alteração do hardware de page walk, então este pode não ser o design ideal para memória enorme, mas é uma extensão sensata para uma CPU de modo duplo que também precisa oferecer suporte ao desempenho máximo para 4- tabelas de nível no formato atual.

— Peter Cordes

Obviamente, com páginas enormes de 2M ou 1G, são apenas 4 ou 3 níveis de tabelas de página do nível superior a uma entrada de tabela de página enorme em vez de um ponteiro de diretório de página.

— Peter Cordes

6

Do meu ponto de vista, este é o resultado do tamanho da página. Cada página contém no máximo 4096/8 = 512 entradas da tabela de páginas. E 2 ^ 9 = 512. Portanto, 9 * 4 + 12 = 48.

— Linzuojian
fonte

4

Para responder à pergunta original: Não houve necessidade de adicionar mais de 48 bits de PA.

Os servidores precisam da quantidade máxima de memória, então vamos tentar ir mais fundo.

1) A maior configuração de servidor (comumente usada) é um sistema de 8 soquetes. Um sistema 8S nada mais é do que 8 CPUs de servidor conectados por uma interconexão coerente de alta velocidade (ou simplesmente, um "barramento" de alta velocidade) para formar um único nó. Existem clusters maiores lá fora, mas eles são poucos e distantes entre si, estamos falando de configurações comumente usadas aqui. Observe que nos usos do mundo real, o sistema 2 Socket é um dos servidores mais comumente usados e o 8S é normalmente considerado de ponta.

2) Os principais tipos de memória usados pelos servidores são memória DRAM regular endereçável por byte (por exemplo, memória DDR3 / DDR4), memória IO mapeada - MMIO (como memória usada por uma placa adicional), bem como espaço de configuração usado para configurar os dispositivos que estão presentes no sistema. O primeiro tipo de memória é aquele que normalmente é o maior (e, portanto, precisa do maior número de bits de endereço). Alguns servidores de ponta também usam uma grande quantidade de MMIO, dependendo da configuração real do sistema.

3) Suponha que cada CPU do servidor possa hospedar 16 DIMMs DDR4 em cada slot. Com um tamanho máximo DDR4 DIMM de 256 GB. (Dependendo da versão do servidor, este número de DIMMs possíveis por soquete é na verdade menor que 16 DIMMs, mas continue lendo para o exemplo).

Portanto, cada soquete pode teoricamente ter 16 * 256 GB = 4096 GB = 4 TB. Para nosso sistema 8S de exemplo, o tamanho da DRAM pode ser no máximo 4 * 8 = 32 TB. Isso significa que o número máximo de bits necessários para endereçar este espaço DRAM é 45 (= log2 32 TB / log2 2).

Não entraremos em detalhes sobre os outros tipos de memória (MMIO, MMCFG etc), mas o ponto aqui é que o tipo de memória mais "exigente" para um sistema de 8 soquetes com os maiores tipos de DDR4 DIMMs disponíveis hoje (256 GB DIMMs) usam apenas 45 bits.

Para um sistema operacional que suporta 48 bits (WS16 por exemplo), existem (48-45 =) 3 bits restantes. O que significa que se usarmos os 45 bits inferiores apenas para 32 TB de DRAM, ainda teremos 2 ^ 3 vezes de memória endereçável que pode ser usada para MMIO / MMCFG para um total de 256 TB de espaço endereçável.

Portanto, para resumir: 1) 48 bits de endereço físico são muitos bits para suportar os maiores sistemas de hoje que estão "totalmente carregados" com grandes quantidades de DDR4 e também muitos outros dispositivos IO que exigem espaço de MMIO. 256 TB para ser exato.

Observe que este espaço de endereço de 256 TB (= 48 bits de endereço físico) NÃO inclui nenhuma unidade de disco como unidades SATA porque NÃO fazem parte do mapa de endereço, eles incluem apenas a memória endereçável por byte e é exposta ao sistema operacional.

2) O hardware da CPU pode optar por implementar 46, 48 ou> 48 bits dependendo da geração do servidor. Mas outro fator importante é quantos bits o sistema operacional reconhece. Hoje, o WS16 oferece suporte a endereços físicos de 48 bits (= 256 TB).

O que isso significa para o usuário é que, mesmo tendo uma CPU de servidor grande e ultramoderna que pode suportar> 48 bits de endereçamento, se você executar um sistema operacional que suporta apenas 48 bits de PA, então você só pode tirar proveito de 256 TB .

3) Em suma, existem dois fatores principais para tirar vantagem de um número maior de bits de endereço (= mais capacidade de memória).

a) Quantos bits seu HW de CPU suporta? (Isso pode ser determinado pela instrução CPUID em CPUs Intel).

b) Qual versão do sistema operacional você está executando e quantos bits de PA ele reconhece / suporta.

O mínimo de (a, b) determinará, em última instância, a quantidade de espaço endereçável da qual seu sistema pode aproveitar.

Escrevi esta resposta sem examinar as outras respostas em detalhes. Além disso, não mergulhei em detalhes nas nuances do MMIO, MMCFG e em toda a construção do mapa de endereços. Mas espero que isso ajude.

Obrigado, Anand K Enamandram, arquiteto de plataforma de servidor Intel Corporation

— Anand K Enamandram
fonte

Esta pergunta está perguntando sobre o tamanho do espaço de endereço virtual de 48 bits (exigindo que os endereços virtuais sejam canônicos). Você quer mais bits virtuais do que bits físicos, portanto, um kernel com metade alta pode mapear toda a memória física em um único espaço de endereço (seu próprio ou espaço do usuário). Como você disse, o HW só precisa implementar tantos bits de PA quanto os controladores DRAM + MMIO podem usar e pode usar qualquer número até o limite de 52 bits no formato de tabela de páginas x86-64. ( Por que em 64 bits o endereço virtual tem 4 bits curtos (48 bits) em comparação com o endereço físico (52 bits)? )

— Peter Cordes

1

O formato de tabela de página de 4 níveis também impõe o limite de VA de 48 bits, até que HW + SW suporte tabelas de página PML5 para VA de 57 bits. De qualquer forma, esta é uma resposta útil, mas parece ter sido postada na pergunta errada. Não tenho certeza se há um lugar melhor para isso, então acho que podemos deixá-lo aqui, espero que com uma edição para adicionar um cabeçalho para dizer algo sobre PA vs. VA.

— Peter Cordes

2

Muitas pessoas têm esse conceito errado. Mas estou prometendo a você que, se você ler isso com atenção, depois de ler todos os seus equívocos ficará claro.

Dizer que um processador de 32 ou 64 bits não significa que ele deve ter um barramento de endereço de 32 bits ou um barramento de endereço de 64 bits, respectivamente! ... Repito, NÃO!

Processador de 32 bits significa que tem ALU (Unidade Aritmética e Lógica) de 32 bits ... isso significa que pode operar em operando binário de 32 bits (ou simplesmente dizendo um número binário com 32 dígitos) e similarmente processador de 64 bits pode operar em binários de 64 bits operando. Portanto, o tempo de um processador de 32 ou 64 bits NÃO significa que a quantidade máxima de memória pode ser instalada. Eles apenas mostram o quão grande o operando pode ser ... (por analogia você pode pensar em uma calculadora de 10 dígitos pode calcular resultados de até 10 dígitos ... ela não pode nos dar 11 dígitos ou qualquer outro resultado maior ... embora seja em decimal, mas estou dizendo esta analogia para simplificar) ... mas o que você está dizendo é o espaço de endereço que é o tamanho máximo da memória diretamente interfaciável (RAM). O carneiro' O tamanho máximo possível é determinado pelo tamanho do barramento de endereços e não é o tamanho do barramento de dados ou mesmo da ALU em que o tamanho do processador é definido (32/64 bits). Sim, se um processador tiver "barramento de endereço" de 32 bits, ele será capaz de endereçar 2 ^ 32 bytes = 4 GB de RAM (ou para 64 bits será 2 ^ 64) ... mas dizendo que um processador de 32 ou 64 bits tem nada relevante para este espaço de endereço (espaço de endereço = até que ponto ele pode acessar a memória ou o tamanho máximo da RAM) e depende apenas do tamanho de sua ALU. Claro que o barramento de dados e o barramento de endereços podem ter o mesmo tamanho e então pode parecer que o processador de 32 bits significa que ele acessará 2 ^ 32 bytes ou 4 GB de memória ... mas é apenas uma coincidência e não será o mesmo para todos.... por exemplo, intel 8086 é um processador de 16 bits (já que tem ALU de 16 bits), então, como você disse, deveria ter acessado 2 ^ 16 bytes = 64 KB de memória, mas não é verdade. Ele pode acessar até 1 MB de memória por ter um barramento de endereço de 20 bits .... Você pode google se tiver alguma dúvida :)

Acho que deixei meu ponto claro. Agora voltando à sua pergunta ... como processador de 64 bits não significa que ele deve ter barramento de endereço de 64 bits, então não há nada de errado em ter um barramento de endereço de 48 bits em um processador de 64 bits ... eles mantiveram o espaço de endereço menor para tornar o design e fabricação baratos .... já que ninguém vai usar uma memória tão grande (2 ^ 64 bytes) ... onde 2 ^ 48 bytes é mais que suficiente hoje em dia.

— hafiz031
fonte

Acho que você deixou seu ponto muito claro, mas há uma coisa que não entendi no que você disse sobre a CPU 8086 de 16 bits: como uma CPU de 16 bits pode lidar com um endereço de 20 bits? Ele lida com isso por meio de uma operação de 2 etapas? Mesmo que o barramento de endereços tenha 20 bits de largura, uma vez que chega à CPU, a largura do registro pode obviamente levar apenas 16 bits ... Como eles fazem isso?

— programadores em

2

Hmm ... operação de 2 etapas. O registro de segmento contém apenas os 16 bits superiores. Em seguida, ele é multiplicado por 10H para chegar a 20 bits e, em seguida, o deslocamento é adicionado.

— hafiz031

1

Não é verdade que apenas 48 bits de baixa ordem de um VA de 64 bits são usados, pelo menos com Intel 64. Os 16 bits superiores são usados, mais ou menos.

A seção 3.3.7.1 Endereçamento canônico no Manual do desenvolvedor de software das arquiteturas Intel® 64 e IA-32 diz:

um endereço canônico deve ter os bits 63 a 48 definidos como zeros ou uns (dependendo se o bit 47 é zero ou um)

Portanto, os bits 47 a 63 formam um superbit, todo 1 ou zero. Se um endereço não estiver na forma canônica, a implementação deve falhar.

Em AArch64, isso é diferente. De acordo com a Visão geral do conjunto de instruções ARMv8 , é um VA de 49 bits.

O sistema de tradução de memória AArch64 suporta um endereço virtual de 49 bits (48 bits por tabela de tradução). Os endereços virtuais têm extensão de sinal de 49 bits e são armazenados em um ponteiro de 64 bits. Opcionalmente, sob o controle de um registro do sistema, os 8 bits mais significativos de um ponteiro de 64 bits podem conter uma "etiqueta" que será ignorada quando usada como um endereço de carga / armazenamento ou o destino de uma ramificação indireta

— Olsonist
fonte

1

Apenas os 48 inferiores são significativos, mas o hardware verifica se o sinal está corretamente estendido para 64 bits. IDK por que eles não especificaram extensão zero; talvez eles quisessem tornar mais conveniente a verificação de um endereço da metade superior vs. inferior (apenas verificando o bit do sinal). Ou talvez para evitar tornar o limite 2 ^ 48 especial, e assim os endereços próximos ao topo podem caber convenientemente em constantes estendidas de sinal de 32 bits. Acho que o último é mais provável.

— Peter Cordes

De qualquer forma, a verificação de HW atual para canônico evita que o software use bits ignorados para ponteiros marcados que quebrarão em HW futuro, então é parte do mecanismo que torna possível estender o hardware futuro se / quando for necessário. (O que poderia ser antes do que eles esperavam, graças à memória não volátil conectada diretamente ao espaço de endereço físico e virtual.)

— Peter Cordes

procfs no Linux em meu Core i5 diz que foi mapeado para 7ffd5ea41000-7ffd5ea62000. Este intervalo de endereços faz sentido de acordo com a regra 'canônica' acima. Os bits 48-63 são 0, tornando-o um endereço canônico correto. O que é um pouco estranho são alguns endereços na fonte do Linux. Em include / asm / pgtable_64_types está escrito #define __VMALLOC_BASE _AC (0xff92000000000000, UL). Este NÃO é um endereço canônico. Esse endereço começaria com 0xffff8. Não sei porquê.

— Olsonist

Sim, o IIRC Linux usa a metade inferior do intervalo canônico para o espaço do usuário e (principalmente) usa a metade superior para mapeamentos apenas do kernel. Mas alguma memória do kernel é exportada para o espaço do usuário, como a [vsyscall]página. (Isso pode ser exportar coisas como o PID atual para que getpid()seja puramente espaço do usuário. Também gettimeofday()pode apenas usar o rdtsc no espaço do usuário + fatores de escala exportados pelo kernel. Embora parte disso seja, eu acho [vdso], que está perto do topo do metade inferior.)

— Peter Cordes,

IDK o que __VMALLOC_BASEfaz. Presumivelmente, não é usado diretamente.

— Peter Cordes

0

Uma CPU é considerada "N-bits" principalmente por seu tamanho de barramento de dados e por grande parte de suas entidades (arquitetura interna) : Registradores, Acumuladores, Unidade Aritmética-Lógica (ALU), Conjunto de Instruções, etc. Por exemplo: O bom e velho CPU Motorola 6800 (ou Intel 8050) é um CPU de 8 bits. Possui um barramento de dados de 8 bits, arquitetura interna de 8 bits e um barramento de endereço de 16 bits.

Embora a CPU de N bits possa ter outras entidades além de N-size. Por exemplo, as melhorias no 6809 sobre o 6800 (ambos são CPU de 8 bits com um barramento de dados de 8 bits). Entre as melhorias significativas introduzidas no 6809 estavam o uso de dois acumuladores de 8 bits (A e B, que poderiam ser combinados em um único registrador de 16 bits, D), dois registradores de índice de 16 bits (X, Y) e dois Ponteiros de pilha de 16 bits.

— Amit G.
fonte

Já existe uma resposta enfatizando este ponto com o Motorola 68000/68020 como exemplo. Esta questão é realmente sobre x86-64 especificamente, não sobre CPUs de 8/16 bits antigas. No caso do x86-64, um dos principais fatores é que endereços virtuais mais amplos precisariam de uma tabela de páginas mais profunda, e esse fator não existia para os chips antigos de que você está falando.

— Peter Cordes

A largura do barramento de dados não precisa corresponder à largura do registrador ou da ALU. Por exemplo, P5 Pentium tem um barramento de dados de 64 bits (cargas / armazenamentos de 64 bits alinhados são garantidamente atômicos), mas os registradores / ALUs são de apenas 32 bits (exceto para a FPU integrada e no Pentium MMX posterior o SIMD ALUs.)

— Peter Cordes

OP escreve: "Minha expectativa era que, se fosse um processador de 64 bits, o espaço de endereço também deveria ser 2 ^ 64." ........ Você escreve: "Esta questão é realmente sobre x86-64 especificamente, não sobre CPUs de 8/16 bits antigas". ........ Acho que você perdeu a essência da questão OP. A questão OP é o resultado da suposição errada de que uma CPU de 64 bits deve ter um barramento de endereço de 64 bits. Sobre a ALU, escrevi grande parte de suas entidades; Nem todos eles.

— Amit G.

Pare de enviar spam para mim postando este comentário novamente. Sim, claro que o OP está errado pelo motivo que você descreveu, mas eu estava observando que sua resposta parece cometer um erro semelhante. Você diz " e, conseqüentemente, grande parte de suas entidades: Registradores e Acumuladores, Unidade Lógica-Aritmética (ALU) ... ", o que soa como se você estivesse dizendo que essas coisas correspondem à largura do barramento de dados. A frase "uma grande parte" implica que você está dizendo quais partes, não que isso só às vezes seja verdade para essas partes.

— Peter Cordes