¿Por qué podría ser difícil hacer una versión de 64 bits de un programa?

En mi corta programación, ha sido trivial compilar cualquiera de mis C ++, Java, etc. para una máquina de 32 o 64 bits siempre que tenga la fuente completa del programa.

Pero no se lanza una gran cantidad de software de 64 bits. Lo más molesto es que todavía no hay una versión de 64 bits del motor de Unity.

¿Qué hace que sea difícil compilar algunos programas para máquinas de 64 bits?

compiler 64-bit 32-bit

— Calben
fuente

porque los programadores estúpidos siguen asumiendosizeof(int)==sizeof(void*)

— fanático del trinquete

La razón principal en nuestro entorno es la dependencia de algunos componentes de terceros que no están disponibles como 64 bits. No sé si eso también se aplica a Unity, pero no me sorprendería demasiado si ese fuera el caso.

— Doc Brown

Pueden usar typedef como int32, int64 para int, float, puntero en lugar de asumir su tamaño. Lo que podría resolver muchos problemas. Muchos de los problemas comienzan desde el momento en que comenzamos a asumir.

— Kshitij

Lo que de hecho es una suposición perfectamente razonable en arquitecturas planas. Windows se equivocó deliberadamente para evitar romper sus propios errores.

— Joshua

¿Por qué sería una suposición razonable? Esperaría tener un decente operator*para int, pero los punteros no necesitan eso. Además, la mayoría de los entornos Linux y Unix también tienen int32 bits.

— MSalters

Respuestas:

El problema general es que es muy fácil codificar supuestos indocumentados en un programa, y es muy difícil encontrar lugares donde se hicieron esos supuestos. Los lenguajes de alto nivel tienden a aislarnos un poco de estas preocupaciones, pero en los lenguajes de nivel inferior utilizados para implementar plataformas y servicios, es fácil hacer cosas que no son necesariamente portátiles en las arquitecturas:

Suponiendo que intsea lo suficientemente grande como para almacenar un puntero
Asumiendo propiedades de la representación de punteros, por ejemplo, para el etiquetado de punteros
Suponiendo que los punteros de datos y los punteros de código tengan el mismo tamaño

También existe la preocupación práctica de la gestión de versiones. Si solo hago una compilación x86, todavía se ejecutará en x86-64, aunque tal vez más lentamente debido a la disponibilidad limitada de registros. Mientras que si construyo para x86 y x86-64, ahora debo probar en ambas arquitecturas y tratar con los errores que solo pueden surgir en una arquitectura, lo que aumenta el costo de envío de una nueva versión.

— Jon Purdy
fuente

Tenga en cuenta que es posible escribir un error que solo se manifiesta cuando se ejecuta un binario x86 en la versión de 64 bits del sistema operativo. Es más difícil ;-)

— Steve Jessop

+1. Me gustaría agregar lo siguiente al punto de "administración de versiones": si mi software se basa en componentes de terceros, incluso si hay una versión de 32 y 64 bits de un componente específico disponible, el esfuerzo adicional para probar nuevas versiones No debe ser subestimado. Entonces, la gestión de lanzamientos de la OMI debe ser el primer punto de esa lista, no solo una nota al margen.

— Doc Brown

¿Podría dar más detalles sobre el problema del tamaño del puntero int? ¿Es porque en un entorno de 64 bits, el espacio de memoria sería mayor de lo que permite un int?

— TankorSmash

@TankorSmash: en x86 normalmente sizeof(int) == sizeof(void *)(ambos son de 32 bits); en x86_64, es normal mantener int32 bits (sigue siendo compatible con x86 y evita desperdiciar espacio en la memoria), pero los punteros deben ser de 64 bits (ya que el espacio de direcciones virtuales sube a 2 ^ 64), por lo que ya no pueden serlo. empujado en un into unsigned int.

— Matteo Italia

La mayoría del software funcionará igual cuando se compila para las arquitecturas Intel / AMD de 32 y 64 bits. Sin embargo, algunos programas no lo harán. Además de la pereza, o llegar a un público más amplio, hay algunas razones específicas por las que la recompilación como 64 bits no funcionará.

El software puede usar operaciones de puntero inseguras. Quizás un programa coloca un puntero en un int, que generalmente es de 32 bits para la mayoría de los compiladores de C y C ++. Los punteros son de 64 bits en un programa de 64 bits. Eso no funciona.
Las operaciones de desplazamiento de bits pueden producir resultados diferentes si el tipo entero que se utiliza es de un tamaño diferente. Esto puede ser un problema cuando se usa un tipo de datos regular en lugar de un tipo estándar definido comoint32_t
Un tipo de datos utilizado en una unión puede cambiar los tamaños, cambiando el comportamiento de la unión.
El software puede depender de bibliotecas que son solo de 32 bits. En general, un programa de 64 bits solo funcionará con bibliotecas de 64 bits debido a suposiciones sobre la pila, punteros, etc.

La dificultad que usted plantea en su pregunta es simplemente que en algunas bases de código puede haber millones de líneas de código que realizan operaciones inseguras, hacen suposiciones inseguras, tienen atajos y "optimizaciones" inteligentes implementadas por los desarrolladores. El código no se compilará en un entorno de 64 bits, o se compilará pero tendrá errores de show-stopper. Puede llevar mucho tiempo solucionar todos los problemas. Tal vez una compañía los arregle con el tiempo hasta que sea posible lanzar una versión de 64 bits. Tal vez una compañía desarrolle una "versión 2" junto con las versiones de mantenimiento actuales porque es necesaria una reescritura total.

La moraleja de la historia es escribir código limpio y no tratar de adivinar el compilador o agregar optimizaciones inteligentes que no son necesarias, pueden romper el software y, de todos modos, probablemente no ayuden.

Este artículo entra en mucho más detalle de lo que podría esperar incluir en esta respuesta: 20 problemas de portabilidad de código C ++ en la plataforma de 64 bits

— Tulains Córdova
fuente

Los problemas pueden ir más allá de la compilación también; Tengo un amigo musciano que no puede usar el FL Studio de 64 bits disponible porque requieren muchos VSTi de solo 32 bits; otras arquitecturas de complementos basadas en enlaces dinámicos se ven afectadas de manera similar.

— StarWeaver

Gracias por la edición: normalmente soy MUY exigente con la gramática, pero cometí algunos errores. Y @StarWeaver creo que mencioné eso cuando dije que el código podría compilarse pero que tenía errores. Esto todavía se remonta a mi punto sobre escribir código limpio para cualquier idioma y plataforma a la que se dirija.

"tiene errores de show-stopper" Los show stopper son obvios y "en su cara" y pueden ser tratados. Lo que creo que es probablemente peor son todos los problemas que producen resultados sutilmente incorrectos que pasarán desapercibidos durante mucho tiempo.

— Burhan Ali