Barrapunto

La mayoría de los micros de 64 bits "de verdad" (sea lo que sea eso) también tienen un modo de 32 bits, igual x86-64.

En igualdad de condiciones el modo de 64 es más lento que el de 32 porque hay menos caché disponible (las etiquetas/direcciones son más grandes, el código y los datos ocupan el doble) y la resolución de las direcciones por parte de la MMU es más lenta así que los fabricantes suelen dar un escape de 32 bits por si quieres mayor rendimiento. Hay una mejora en velocidad por usar registros de 64 bits pero en un programa normal con el patrón de accesos a memoria habitual se nota poco y el balance global es que es más lento.

En x86-64 es atípico porque precisamente se da el caso contrario: el modo 64 es más rápido que el de 32. Esto es debido a que en el primer modo incluye cambios drásticos a nivel de microarquitectura (no solo un pequeño parche) como aumentar el número de registros disponibles.

Por otro lado, en micros "de verdad" como UltraSparc el código de 64 (v9) es bastante más lento que el de 32 (v8). La máquina soporta ambos y lo normal es que todo el userspace del SO se compile para 32 bits salvo que necesites expresamente las direcciones de 64 bits (una base de datos enorme, por ejemplo). Como alternativa de compromiso ofrece un modo mixto, el v8plus: registros generales de 64 bits con direcciones de 32.

Vaya, yo creía que el hecho de decir "es una arquitectura de x bits" dependía del ancho de los registros de propósito general y del ancho de la ALU (sin contar extensiones SIMD o las operaciones de la FPU).

En el caso del x86-64 la ALU opera con 64 bits, los registros de propósito general son de 64 bits y puede trabajar con direcciones de memoria de 8 bytes.

Qué le falta para ser 64 bits "de verdad"?