El conjunto de instrucciones x86-64 agrega más registros y otras mejoras para ayudar a optimizar el código ejecutable. Sin embargo, en muchas aplicaciones, el aumento del tamaño del puntero es una carga. Los bytes adicionales no utilizados en cada puntero obstruyen la caché e incluso pueden desbordar la RAM. GCC, por ejemplo, se construye con el indicador -m32, y supongo que este es el motivo.Punteros de 32 bits con el ISA x86-64: ¿por qué no?
Es posible cargar un valor de 32 bits y tratarlo como un puntero. Esto no necesita instrucciones adicionales, simplemente cargue/calcule los 32 bits y cargue desde la dirección resultante. El truco no será portátil, ya que las plataformas tienen diferentes mapas de memoria. En Mac OS X, se reserva todo el bajo espacio de direcciones de 4 GiB. Aún así, para un programa que escribí, añadí hackosamente 0x100000000L a "direcciones" de 32 bits antes de usar un rendimiento mejorado en gran medida en direcciones de 64 bits reales, o compilar con -m32.
¿Hay algún impedimento fundamental para tener una plataforma x86-64 de 32 bits? Supongo que apoyar tal quimera agregaría complejidad a cualquier sistema operativo, y cualquiera que quiera ese último 20% debería simplemente hacer que funcione ™, pero parece que este sería el mejor para una variedad de programas computacionalmente intensivos.
Los datos de generación de perfiles en la mayoría de las aplicaciones sugieren que no hay pérdidas significativas debido al aumento del tamaño del puntero. – Puppy
El Compilador Intel tiene la opción ['Qauto-ilp32'] (http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/copts/ccpp_options/option_qauto_ilp32 .htm) que "intenta" usar 32 bits para punteros, incluso en modo x64. – Mysticial
@Mysticial, pero eso se parece más a los antiguos indicadores 'near' y' far', ¿verdad? Esa solución está bien, supongo, pero no es tan limpia como la que me refiero. – Potatoswatter