¿Puede funcionar un SO de 32 bits en un procesador de 64 bits?

Su pregunta es específica de la arquitectura. x64 es esencialmente una extensión de la arquitectura x86. Soporta un espacio de direcciones de 64 bits. Proporciona algunas instrucciones y registros nuevos.

Puede ejecutar Windows x86 de 32 bits en una máquina x64. Tenga en cuenta que no puede hacerlo en sistemas Itanium de 64 bits.

La respuesta actualmente aceptada es generalmente correcta, pero no lo es específicamente. En realidad, no hay una cosa que se llame “CPU de 32 bits” o “CPU de 64 bits”: es una descripción que se refiere sólo a una pequeña parte de la arquitectura de la CPU. En concreto, hace referencia al número de líneas de selección de direcciones entre la CPU y la memoria, es decir, al llamado espacio de direcciones disponible para las operaciones de memoria.

En los días de antaño cuando la CPU cuando la gente solía sentarse y tejer (envolver) los cables entre un procesador y la memoria, usted habría tenido que utilizar ya sea 32 o (teóricamente, porque no existía en ese momento) 64 cables entre la CPU y el controlador de memoria que se utilizaría para especificar qué dirección de memoria que quería acceder. Por ejemplo, digamos que tenemos una arquitectura de memoria de 2 bits: el envío de 00 seleccionaría la dirección 0, 01 seleccionaría la dirección 1, 10 seleccionaría la dirección 2 y 11 seleccionaría la dirección 3. Estos 2 bits nos dan 2^2 bytes de RAM (4 bytes).

Si tomas una CPU de 32 bits y le añades 32 cables más entre la CPU y el controlador de memoria para que mágicamente pueda soportar más memoria, ahora tienes una “CPU de 64 bits” que puede ejecutar código de 32 bits o de 64 bits. ¿Qué significa esto y cómo ocurre? Bueno, tomemos nuestra CPU de 2 bits de la parte anterior de esta respuesta y agreguemos otro cable, convirtiéndola en una CPU de 3 bits, llevándonos de 4 bytes a 2^3 u 8 bytes de RAM.

El código existente de “2 bytes” se ejecutará, estableciendo los valores de los 2 últimos hilos como se indicó anteriormente (00-11). Cablearemos la conexión extra para que sea cero por defecto, así que en realidad cuando el código de 2 bytes se ejecuta, cuando selecciona 00, en realidad está seleccionando 000 y cuando selecciona 11 en realidad está seleccionando 011. Fácil.

Ahora un programador quiere escribir código “nativo” de 3 bytes y escribe su software para aprovechar el espacio de direcciones extra. Le dice a la CPU que sabe lo que está haciendo y que tomará el control manual de los nuevos cables extra. Su software conoce los cables extra y envía correctamente 000-111, dándole acceso completo al rango de memoria soportado por esta nueva arquitectura de CPU.

Pero no es así como tiene que ocurrir. De hecho, normalmente no es así como suceden las cosas. Cuando se introdujeron por primera vez las CPU de 64 bits (y hubo muchas), todas fueron con arquitecturas/diseños completamente nuevos. No se limitaron a añadir 32 hilos adicionales y decir “aquí tienes, esta es una CPU de 64 bits que puedes usar en modo de 32 o 64 bits”, sino que dijeron “Esta es nuestra nueva CPU y sólo requiere programación en este lenguaje de máquina totalmente nuevo, se comporta de esta forma totalmente nueva, resuelve un billón de problemas diferentes de forma mucho más elegante que las antiguas CPUs x86/i386 de 32 bits, y es una arquitectura nativa de 64 bits. Diviértete”.

Esa fue la historia del Intel Itanium, ahora conocido como el “Itanic” por lo mucho que se hundió. Se suponía que iba a anunciar la nueva era de los 64 bits, y era algo digno de ver. Instrucciones de longitud variable, cachés enormes, espacio de direcciones de 64 bits, toneladas de registros, súper emocionante, súper genial y súper difícil de convencer a todo el mundo de que recompilara o reescribiera 20 años de código heredado. Esto fue en la época en que AMD e Intel competían realmente, y AMD tuvo la brillante idea de decir “olvidémonos de todo este asunto de "resolver todos los problemas del mundo” y simplemente añadamos 32 hilos más al i386 y hagamos una CPU de 64 bits compatible con 32 bits" y nació la arquitectura de CPU x86_64.

De hecho, si miras los nombres del kernel y las fuentes de los principales sistemas operativos (Linux, Windows, BSD, etc.) los encontrarás plagados de referencias a las CPUs AMD64 y a la arquitectura AMD64. AMD ideó una estrategia ganadora para conseguir que todo el mundo se pasara al mundo de los 64 bits y, al mismo tiempo, preservar la compatibilidad con las aplicaciones de 32 bits, de forma que un sistema operativo de 32 bits pudiera ejecutarse en un hardware de 64 bits o incluso que las aplicaciones de 32 bits pudieran ejecutarse en un sistema operativo de 64 bits en un hardware de 64 bits. Intel siguió su ejemplo más pronto que tarde con su arquitectura “Intel EM64T” (que era básicamente idéntica a AMD64) y x86_64 se impuso mientras que el Itanic y otros como MIPS64 y ALPHA64 dejaron de verse en el mercado de los ordenadores de sobremesa/servidores.

tl;dr Las CPUs amd64 aka x86_64 están diseñadas para ser compatibles con el núcleo y el código de 32 y 64 bits, pero la mayoría de las CPUs de 64 bits son decididamente no compatibles hacia atrás de la misma manera. Una CPU de 32 bits puede acceder como máximo a 4GiB de memoria, mientras que una CPU de 64 bits puede acceder a unos impresionantes 16 EiBs (16 × 1024^6 bytes, o 4 billones de veces más memoria que 4GiB).

Tanto un sistema operativo de 32 como de 64 bits puede funcionar en un procesador de 64 bits, pero el sistema operativo de 64 bits puede utilizar toda la potencia del procesador de 64 bits (registros más grandes, más instrucciones); en resumen, puede hacer más trabajo en el mismo tiempo. Un procesador de 32 bits sólo admite el sistema operativo Windows de 32 bits.