Perché potrebbe essere difficile creare una versione a 64 bit di un programma?

Nella mia breve programmazione, è stato banale compilare uno qualsiasi dei miei C ++, Java, ecc. Per una macchina a 32 o 64 bit fintanto che ho la fonte completa per il programma.

Ma molti software non vengono rilasciati a 64 bit. Più fastidiosamente, non esiste ancora una versione a 64 bit del motore Unity.

Cosa rende difficile compilare alcuni programmi per macchine a 64 bit?

compiler 64-bit 32-bit

— calben
fonte

perché gli stupidi programmatori continuano a supporresizeof(int)==sizeof(void*)

— maniaco del cricchetto

Il motivo principale nel nostro ambiente è la dipendenza da alcuni componenti di terze parti che non sono disponibili come 64 bit. Non so se questo vale anche per Unity, ma non sarei troppo stupito se fosse così.

— Doc Brown

Possono usare typedef come int32, int64 per int, float, pointer invece di assumerne la dimensione. Il che potrebbe risolvere molti problemi. Molti dei problemi iniziano dal momento in cui iniziamo a supporre.

— Kshitij,

Che in realtà è un presupposto perfettamente ragionevole per architetture piatte. Windows ha sbagliato deliberatamente per evitare di rompere i propri errori.

— Joshua

Perché sarebbe un presupposto ragionevole? Mi aspetterei di avere un decente operator*per int, ma i puntatori non ne hanno bisogno. Inoltre, la maggior parte degli ambienti Linux e Unix ha anche inta 32 bit.

— Salterio

Risposte:

Il problema generale è che è molto facile codificare assunzioni non documentate in un programma e molto difficile trovare luoghi in cui tali assunzioni sono state fatte. I linguaggi di alto livello tendono a isolarci da queste preoccupazioni in qualche modo, ma nei linguaggi di livello inferiore utilizzati per l'implementazione di piattaforme e servizi, è facile fare cose che non sono necessariamente portatili in tutte le architetture:

Supponendo che intsia abbastanza grande per memorizzare un puntatore
Supponendo le proprietà della rappresentazione dei puntatori, ad es. Per la marcatura dei puntatori
Supponendo che i puntatori di dati e i puntatori di codice abbiano le stesse dimensioni

C'è anche la preoccupazione pratica della gestione delle versioni. Se realizzo solo una build x86, verrà comunque eseguita su x86-64, anche se forse più lentamente a causa della disponibilità limitata dei registri. Considerando che se creo sia per x86 che per x86-64, ora devo testare su entrambe le architetture e affrontare i bug che possono sorgere su una sola architettura, aumentando il costo della spedizione di una nuova versione.

— Jon Purdy
fonte

Si noti che è possibile scrivere un bug che si manifesta solo quando un binario x86 viene eseguito sulla versione a 64 bit del sistema operativo. È solo più difficile ;-)

— Steve Jessop

+1. Vorrei aggiungere quanto segue al punto "gestione delle versioni": se il mio software si basa su componenti di terze parti, anche se è disponibile una versione a 32 e 64 bit di un componente specifico, lo sforzo aggiuntivo per testare nuove versioni non dovrebbe essere sottovalutato. Quindi la gestione delle versioni di IMHO dovrebbe essere il primo punto in quella lista, non solo una nota a margine.

— Doc Brown

Potresti approfondire il problema della dimensione del puntatore int? È perché in un ambiente a 64 bit, lo spazio di memoria sarebbe superiore a quello che consente un int?

— TankorSmash

@TankorSmash: normalmente su x86 sizeof(int) == sizeof(void *)(sono entrambi a 32 bit); su x86_64, è normale mantenere int32 bit (rimane compatibile con x86 ed evita di sprecare spazio in memoria), ma i puntatori devono essere a 64 bit (poiché lo spazio degli indirizzi virtuali arriva fino a 2 ^ 64), quindi non possono più essere spinto in un into unsigned int.

— Matteo Italia,

La maggior parte dei software funzionerà allo stesso modo se compilata per 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ù vasto, ci sono alcuni motivi specifici per cui la ricompilazione come 64 bit non funzionerà.

Il software può utilizzare operazioni con puntatori non sicuri. Forse un programma inserisce un puntatore in un int, che in genere è a 32 bit per la maggior parte dei compilatori C e C ++. I puntatori sono 64 bit in un programma a 64 bit. Questo non funziona
Le operazioni di spostamento dei bit possono produrre risultati diversi se il tipo intero utilizzato è di dimensioni diverse. Questo può essere un problema quando si utilizza un tipo di dati normale anziché un tipo standard comeint32_t
Un tipo di dati utilizzato in un'unione può cambiare dimensioni, modificando il comportamento dell'unione.
Il software può fare affidamento su librerie che sono solo a 32 bit. In generale, un programma a 64 bit funzionerà solo con librerie a 64 bit a causa di ipotesi su stack, puntatori, ecc.

La difficoltà che ti chiedi nella tua domanda è semplicemente che in alcune basi di codice potrebbero esserci milioni di righe di codice che eseguono operazioni non sicure, fanno ipotesi non sicure, hanno scorciatoie e "ottimizzazioni" intelligenti messe dagli sviluppatori. Il codice non verrà compilato in un ambiente a 64 bit oppure verrà compilato ma avrà bug di show-stopper. Potrebbe richiedere 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 un'azienda svilupperà una "versione 2" insieme alle versioni di manutenzione correnti perché è necessaria una riscrittura totale.

La morale della storia è scrivere codice pulito e non tentare di indovinare il compilatore o aggiungere ottimizzazioni intelligenti che non sono necessarie, possono rompere il software e probabilmente non aiutano comunque.

Questo articolo è molto più dettagliato di quanto potrei sperare di includere in questa risposta: 20 problemi di porting del codice C ++ sulla piattaforma a 64 bit

— Tulains Córdova
fonte

I problemi possono andare oltre la semplice compilazione; Ho un amico muscoloso che non può usare il FL Studio a 64 bit disponibile perché richiedono molti VSTi a soli 32 bit; altre architetture di plugin basate sul collegamento dinamico sono influenzate in modo simile.

— StarWeaver,

Grazie per la modifica: di solito sono MOLTO esigente per la grammatica ma ho commesso alcuni errori. E @StarWeaver penso di averlo toccato quando ho detto che il codice poteva essere compilato ma aveva dei bug. Questo risale ancora al mio punto di scrivere codice pulito per qualsiasi lingua e piattaforma tu stia prendendo di mira.

"have bugs show-stopper" I tappi show sono ovvi e "in faccia" e possono essere risolti. Quello che penso sia probabilmente peggio sono tutti i problemi che producono risultati sottilmente errati che passeranno inosservati per molto tempo.

— Burhan Ali,