His,
Antes de mais tenho a certeza que nos actuais cpus de 32 bits da amd e intel para desktop só podes aceder a 4GB de memória (virtual que seja).
Isso é comprovado, para além dos vários sites da especialidade, pelos próprios documentos da AMD:
Because of this, 16-bit and 32-bit applications running in
compatibility mode can access only the low 4GB of the longmode
virtual-address space. Likewise, a 32-bit address
generated in 64-bit mode can access only the low 4GB of the
long-mode virtual-address space.
...
E logo no ínicio:
It adds 64-bit addressing...
...
The need for a 64-bit x86 architecture is driven by applications
that address large amounts of virtual and physical memory,
such as high-performance servers, database management
systems, and CAD tools. These applications benefit from both
64-bit addresses and an increased number of registers.
...
in "AMD64 Architecture Programmer's Manual Volume 1: Application Programming"
Quanto à parte do CAS e RAS, penso que isso não tem a ver com o que estamos a falar, CAS e RAS tem a ver com a organização interna da memória, o cpu está-se a lixar se a memória tem muitas linhas ou muitas colunas, o controlador é que trata disso
E o controlador é que precisa de um endereço de memória para saber como o ir buscar (e tratar do CAS e RAS respectivo), que eu saiba os endereços de memória não se referem a CAS e/ou RAS mas a endereços absolutos, o controlador é que fará a tradução.
Mas antes de mais já estamos a ir por um caminho errado dado que o limite de endereçamento não é de memória propriamente mas sim de memória virtual que basicamente é um metodo de abstracção para mesmo tendo 128MB de Ram poderes aceder a ficheiros maiores, um endereço na memoria virtual tanto pode apontar para sitios na memória Ram ou no disco e/ou outros dispositivos... Eu tinha uma melhor definição mas é num livro e tenho preguiça em passar, por isso aqui fica mais um quote dos amd tech docs:
Virtual Memory Virtual memory consists of the entire address space available to programs. It is a large linear-address space that is translated by a combination of hardware and operating-system software to a smaller physical-address space, parts of which are located in memory and parts on disk or other external storage media.
Do meu (humildemente pouco) conhecimento das arquitecturas actuais o que o cpu precisa de ter nos registos e portanto passar ao controlador de memória é um endereço de memória virtual do que quer aceder e no caso actual dos cpus de 32 bits, ele só cns enviar 32 bits logo só dá para aceder a 2^32 bits de endereços de memória.
O que falas de se "fazerem 2 viagens" de por exemplo 2 vezes 32 bits nunca vi aplicado em nenhum processador e não estou bem a ver como o fazias em termos de hardware propriamente dito (comparadores,mux's,etc), no máximo daria para teres 2 caminhos para endereços de memória, 1 para a linha e outro para a coluna só que nesse caso basicamente tens um endereço de 64 bits logo o teu cpu seria de 64 bits

ou então terias um registo na própria memória de 64 bits para armazenar os primeiros 32 bits e dps juntar aos outros 32 da 2ª viagem...
Já me afastei um bocado do objectivo do post, mas, como vês é mais q possivel com apenas 16 bits aceder independentemente a 4Gigas de memoria Ram.
Mas não será que usaste 32 bits como endereço? 16 para RAS e 16 para CAS?
Quanto à memoria do CPU... Qual é o objectivo dela? Ser rápida, ter os valores mais usados, ter os valores indispensáveis para as operações actuais da ALU e ter valores de controlo (status words nos intel) . Logo vai ser muito pequena, só precisam de caber lá uma mao cheia de registos.
Memória do CPU é mesmo um termo exacto para dar confusão

Isto porque não sei se te referes aos registos ou à cache L1 que tmb está no cpu

Mas quanto a isso não tenhas dúvidas que o maior número de registos dá muito jeito em termos de performance, especialmente para evitar os hazards.
P.S.- Quanto ao truque dos Xeon, estive a pensar e como já disse n faço ideia mas calculo que seja algo baseado em não utilizar endereços efectivos de memórias mas sim endereçamento por deslocamento, nomeadamente vários deslocamentos com o inerente bottleneck que daí advém em termos de performance. Porque é que esta solução é má? Simples: pk tu tmb para chegares aqui ao site não vais primeiro ao sapo, dps clicas num link para o google, dps para o yahoo, dps para num-sei-onde e dps num link para o site mas sim usas o endereço directo do site (ou bookmark

)...
Edit - Relendo o que já disse e clarificando melhor: o limite está no endereço de memória virtual (virtual addresses) é esse que é de 64 bits, a memória virtual é basicamente uma lista telefonica com endereços para a memória fisica e para o disco e uma das vantagens é poderes ter programas maiores que a memória física, ao dizeres um endereço virtual que está no disco é responsabilidade do hardware/software de o meter em memória física (na maioria dos casos) e de lá chegar correctamente.
Quando a informação que o virtual address pretende chegar está disponivel em memória então o "anão que vive dentro do teu computador" é que vai traduzir o endereço para um endereço físico na memória "physical address".
Esse é o endereço que chega aos modulos de memória e aí é que se dá o que já falaste do RAS e CAS que normalmente é enviado "à vez" como tmb já referiste simplesmente pk fica dispendioso ter um bus grande para este tipo de dados, mas depende da arquitectura, claro! E é também outro dos factores que tornam os acessos à memória Ram lentos...
E depois também há outros pormenores nos tais 64 bits do endereço de memória porque nem todos são usados para isso, daí que o que limite de physical address é um pouco mais baixo.
Mas quem tenha já feito Arquitectura de Computadores I / II ou + que se pronuncie que eu sou só um aprendiz de feiticeiro
E quem quiser aprender mais ou entender o que raio estamos para aqui a falar pode sempre aproveitar para comprar uma das bíblias na matéria (que eu pessoalmente recomendo):
http://www.amazon.co.uk/exec/obidos/ASI ... arcompt-21
Computer Architecture: A Quantitative Approach - by John L. Hennessy, David A. Patterson
E ainda aproveita para nos dar a ganhar uma percentagem da venda do livro para ajudar a sustentar o hosting do site
