Nel mio breve periodo di programmazione, è stato banale compilare uno qualsiasi dei miei C ++, Java, ecc. per una macchina a 32 o 64 bit, purché disponga del sorgente completo per il programma.
Ma molti software non sono rilasciati a 64 bit. Il più fastidioso, non c'è ancora una versione a 64 bit del motore Unity.
Che cosa rende difficile la compilazione di alcuni programmi per macchine a 64 bit?
Il problema generale è che è molto facile codificare ipotesi non documentate in un programma e molto difficile trovare i luoghi in cui sono state fatte queste ipotesi. I linguaggi di alto livello tendono a isolarci un po 'da queste preoccupazioni, ma nei linguaggi di livello inferiore utilizzati per l'implementazione di piattaforme e servizi, è facile fare cose che non sono necessariamente portabili tra le architetture:
Supponendo che int sia abbastanza grande per memorizzare un puntatore
Supponendo le proprietà della rappresentazione dei puntatori, ad es. per tagging del puntatore
Supponendo che i puntatori di dati e i puntatori di codice abbiano le stesse dimensioni
Esiste anche la preoccupazione pratica della gestione dei rilasci. Se creo solo una versione x86, funzionerà ancora su x86-64, anche se forse più lentamente a causa della limitata disponibilità di registri. Considerando che se costruisco sia per x86 che per x86-64, ora devo testare entrambe le architetture e gestire i bug che possono sorgere solo su un'architettura, aumentando il costo di spedizione di una nuova versione.
La maggior parte dei software funzionerà allo stesso modo quando compilata per entrambe le architetture Intel / AMD a 32 e 64 bit. Tuttavia, alcuni software non lo faranno. A parte la pigrizia o il raggiungimento di un pubblico più ampio, ci sono alcuni motivi specifici per cui ricompilare come 64 bit non funzionerà.
Il software potrebbe utilizzare operazioni di puntatore non sicure. Forse un programma mette un puntatore in un int, che è generalmente a 32 bit per la maggior parte dei compilatori C e C ++. I puntatori sono 64 bit in un programma a 64 bit. Non funziona.
Le operazioni di cambio bit possono produrre risultati diversi se il tipo intero utilizzato è di dimensioni diverse. Questo potrebbe essere un problema quando si utilizza un tipo di dati normale anziché un typedef standard come int32_t
Un tipo di dati utilizzato in un'unione può cambiare dimensioni, cambiando il comportamento dell'unione.
Il software può fare affidamento su librerie solo a 32 bit. In generale, un programma a 64 bit funzionerà solo con le librerie a 64 bit a causa di ipotesi su stack, puntatori, ecc.
La difficoltà che poni nella tua domanda è semplicemente che in alcune basi di codice ci possono essere milioni di righe di codice che eseguono operazioni non sicure, fanno ipotesi poco sicure, hanno scorciatoie e intelligenti "ottimizzazioni" inserite dagli sviluppatori. Il codice non verrà compilato in un ambiente a 64 bit, o verrà compilato ma con bug di tipo "show-stopper". Potrebbe essere necessario molto tempo per risolvere tutti i problemi. Forse una società li risolverà nel tempo fino a quando non sarà possibile rilasciare una versione a 64 bit. Forse una società svilupperà una "versione 2" insieme alle attuali versioni di manutenzione perché è necessaria una riscrittura totale.
La morale della storia è scrivere codice pulito e non cercare di indovinare il compilatore o aggiungere intelligenti ottimizzazioni che non sono necessarie, possono rompere il software e probabilmente non aiutano comunque.
Questo articolo va molto più in dettaglio di quanto potrei sperare di includere in questa risposta: 20 problemi di porting del codice C ++ su la piattaforma 64-bit