Um SO de 32 bit pode funcionar num processador de 64 bit?

A sua pergunta é específica da arquitectura. x64 é essencialmente uma extensão à arquitectura x86. Suporta um espaço de endereços de 64 bits. Fornece algumas novas instruções e novos registos.

Pode executar Windows x86 de 32 bits numa máquina x64. Note-se que não pode fazer isto em sistemas Itanium 64-bit.

A resposta actualmente aceite é geralmente correcta, mas não especificamente. Não existe realmente uma única coisa chamada “CPU de 32 bits” ou “CPU de 64 bits” - é uma descrição que se refere apenas a uma pequena parte da arquitectura da CPU. Em particular, refere-se ao número de linhas de selecção de endereços entre a CPU e a memória, ou seja, o chamado espaço de endereços disponível para operações de memória.

Nos dias de antigamente, quando a CPU quando as pessoas costumavam sentar-se e tecer (enrolar) os fios entre um processador e a memória, ter-se-ia de utilizar 32 ou (teoricamente, porque não existia na altura) 64 fios entre a CPU e o controlador de memória que seriam utilizados para especificar qual o endereço de memória a que se queria aceder. Por exemplo, digamos que temos uma arquitectura de memória de 2 bits: o envio de 00 seleccionaria o endereço 0, 01 seleccionaria o endereço 1, 10 seleccionaria o endereço 2, e 11 seleccionaria o endereço 3. Este 2 bits dá-nos 2^2 bytes de RAM (4 bytes).

Se pegar num CPU de 32 bits e adicionar mais 32 fios entre o CPU e o controlador de memória para que possa suportar magicamente mais memória, tem agora um “CPU de 64 bits” que pode executar código de 32 bits ou código de 64 bits. O que é que isto significa e como é que isto acontece? Bem, vamos pegar no nosso CPU de 2 bits da parte anterior desta resposta e adicionar outro fio, transformando-o num CPU de 3 bits, levando-nos de 4 bytes para 2^3 ou 8 bytes de RAM.

O código “2 bytes” existente será executado, definindo os valores dos últimos 2 fios como indicado acima (00-11). A ligação extra será zero por defeito, portanto, quando o código de 2 bytes é executado, quando selecciona 00, está de facto a seleccionar 000 e quando selecciona 11 está de facto a seleccionar 011. Fácil.

Agora um programador quer escrever código de 3 bytes “nativo” e escreve o seu software para tirar partido do espaço de endereços extra. Ela diz ao CPU que sabe o que está a fazer e que vai assumir o controlo manual dos novos fios extra. O seu software sabe do(s) fio(s) extra e envia correctamente 000-111, dando-lhe acesso total à gama de memória suportada por esta nova arquitectura de CPU.

Mas não é assim que tem de acontecer. Na verdade, normalmente é assim não como as coisas acontecem. Quando as CPUs de 64 bits foram introduzidas pela primeira vez (e havia muitas), todas elas foram com arquitecturas/desenhos totalmente novos. Eles não se limitaram a colocar mais 32 fios e disseram “aqui tens, este é um CPU de 64-bit que podes usar no modo 32-bit ou 64-bit”, mas antes disseram “Este é o nosso novo CPU e só precisa de programação nesta linguagem de máquina inteiramente nova, comporta-se desta forma inteiramente nova, resolve um bazilhão de problemas diferentes muito mais elegantemente do que as antigas CPUs de 32-bit x86/i386 alguma vez o fizeram, e é uma arquitectura nativa de 64-bit. Divirtam-se”.

Essa foi a história do Intel Itanium, agora conhecido como o “Itanic” devido à sua enorme afundamento. Era suposto anunciar na nova era dos 64 bits, e era algo para se ver. Instruções de comprimento variável, caches enormes, espaço de endereços de 64 bits, toneladas de registos, super emocionante, super fixe, e super difícil de convencer todos a recompilar ou reescrever 20 anos de código legado para. Isto foi quando a AMD e a Intel estavam realmente a competir, e a AMD teve a brilhante ideia de dizer “vamos esquecer tudo isto ‘resolver todos os problemas do mundo’ e simplesmente adicionar mais 32 fios ao i386 e tornar um CPU de 64 bits compatível com 32 bits” e nasceu a arquitectura do CPU x86_64.

De facto, se olhar para os nomes e fontes dos kernel dos principais sistemas operativos (Linux, Windows, BSDs, etc.) vai encontrá-los repletos de referências às CPUs AMD64 e à arquitectura AMD64. A AMD concebeu uma estratégia vencedora para levar todos a mudar para o mundo dos 64 bits, preservando a compatibilidade com aplicações de 32 bits, de modo a que um SO de 32 bits pudesse correr em hardware de 64 bits ou mesmo aplicações de 32 bits pudessem correr num SO de 64 bits em hardware de 64 bits. A Intel seguiu o conjunto mais cedo e não mais tarde com a sua arquitectura “Intel EM64T” (que era basicamente idêntica à AMD64) e x86_64 ganhou enquanto o Itanic e outros como MIPS64 e ALPHA64 já não eram vistos no mercado de desktop/servidor.

tl;dr amd64 aka x86_64 CPUs foram concebidas para serem compatíveis tanto com kernel e código de 32 e 64-bit, mas a maioria das CPUs de 64-bit são decididamente não retrocompatíveis da mesma forma. Um CPU de 32-bit pode aceder no máximo a 4GiB de memória, enquanto que um CPU de 64-bit pode aceder a um impressionante 16 EiBs (16 × 1024^6 bytes, ou 4 mil milhões vezes mais memória do que 4GiB).

Tanto um SO de 32 e 64 bits pode funcionar num processador de 64 bits, mas o SO de 64 bits pode usar a potência total do processador de 64 bits (registos maiores, mais instruções) - em suma, pode fazer mais trabalho ao mesmo tempo. Um processador de 32 bits suporta apenas o SO Windows de 32 bits.