View Full Version : [C++] g++ Big endian flag
Ciao ragazzi,
sto lavorando su architettura PowerPC. Ho bisogno di convertire i miei dati in big endian. Quindi, il programma che crea i files binari devo ricompilarlo. Quale è il flag da usare in g++ per fare questo?
l'opzione -big non funziona.
Grazie.
ilsensine
05-03-2008, 19:14
-mbig (o -mbig-endian)
Ma il gcc per PowerPC non è big endian di default?
-mbig (o -mbig-endian)
Ma il gcc per PowerPC non è big endian di default?
Guarda, siceramente non lo so. Comunque quelle due opzioni le ho provate, ma mi dice:
cc1plus: error: invalid option `big'
Mi è venuto il sospetto che nel mio applicativo ci sia questo problema, in quanto, andando a leggere i files binari, i valori sono tutti sballati. Cosa che non è mai successa su architetture Intel ed Amd. O il problema è questo, o quello che ho postato qua:
http://www.hwupgrade.it/forum/showthread.php?t=1693840
ilsensine
05-03-2008, 19:31
Se il tuo programma va in esecuzione, allora l'endianess è corretta altrimenti non ti partiva proprio.
Riguardo l'accesso ai dati, deve essere _tua_ responsabilità gestire l'endianess dei dati. Ad esempio un semplice
int a = 0x01020304;
fwrite(&a, sizeof(a), 1, file);
scrive per forza due cose diverse su processori little o big endian, e non c'è flag di compilazione che può aiutarti.
Se il tuo programma va in esecuzione, allora l'endianess è corretta altrimenti non ti partiva proprio.
Riguardo l'accesso ai dati, deve essere _tua_ responsabilità gestire l'endianess dei dati. Ad esempio un semplice
int a = 0x01020304;
fwrite(&a, sizeof(a), 1, file);
scrive per forza due cose diverse su processori little o big endian, e non c'è flag di compilazione che può aiutarti.
No aspetta, non ho capito. Ad esempio, io ho un file binario in cui ho scritto dei double. Se setto il flag per big endian nel programma che crea il file e lo stesso in quello che lo legge, perché devo cambiare le routines di lettura/scrittura?:confused: Allora quei flags a cosa servono? Non dovrò mica riscrivere tutte le routines? :muro:
Il file binario in questione l'ho ricreato sotto architettura Power, ovviamente.
ilsensine
06-03-2008, 10:12
No aspetta, non ho capito. Ad esempio, io ho un file binario in cui ho scritto dei double. Se setto il flag per big endian nel programma che crea il file e lo stesso in quello che lo legge, perché devo cambiare le routines di lettura/scrittura?:confused:
Per i double non lo so, non so se sono scritti in formato diverso tra little/big endian. Bella questione, qualcuno ne sa qualcosa?
Per gli int ti assicuro che avrai problemi.
Allora quei flags a cosa servono?
A compilare il codice in modo da usare l'endianess corretta per il processore target. Certi processori possono operare in little o big endian (viene fissato dal s/o), in questi casi devi dire al gcc per quale tipo di architettura vuoi fare l'eseguibile. Un eseguibile per big endian non può essere eseguito su processori little endian, e viceversa.
Mi risulta che il PowerPC sia solo big endian, magari mi sbaglio.
Non dovrò mica riscrivere tutte le routines? :muro:
Probabilmente. Il problema della compatibilità dei dati tra little e big endian dovevi già pianificarla dall'inizio, se era un requisito.
Per i double non lo so, non so se sono scritti in formato diverso tra little/big endian. Bella questione, qualcuno ne sa qualcosa?
Per gli int ti assicuro che avrai problemi.
Fortunatamente uso solo double.
A compilare il codice in modo da usare l'endianess corretta per il processore target. Certi processori possono operare in little o big endian (viene fissato dal s/o), in questi casi devi dire al gcc per quale tipo di architettura vuoi fare l'eseguibile. Un eseguibile per big endian non può essere eseguito su processori little endian, e viceversa.
Mi risulta che il PowerPC sia solo big endian, magari mi sbaglio.
Mm, scusa ma continua a non tornarmi. Io ho ricompilato tutti i miei sorgenti sotto architettura Power. Quindi, tutti gli eseguibili seguono la codifica big endian quando leggo e scrivo. Di conseguenza, se opero sempre e solo sotto architettura Power, non dovrei preoccuparmi di convertire, perchè non c'è nulla da convertire essendo già tutto in big endian. Ovviamente se passo da un'architettura all'altra dovrei farlo certo. O no?
Fammi capire: ti serve un formato generico per scrivere i dati in un file binario che sia compatibile con endianess diverse ?
Imho settare l'endianess non serve a niente, a meno che l'architettura di destinazione non supporti formati eseguibili con endiness diversi.
Se non setti l'endianess e rimani sulla stessa architettura non ti devi occupare del problema.
ilsensine
06-03-2008, 10:26
Di conseguenza, se opero sempre e solo sotto architettura Power, non dovrei preoccuparmi di convertire, perchè non c'è nulla da convertire essendo già tutto in big endian.
Ah allora se quei file non verranno mai letti da processori little endian non c'è nessun problema. Li vedi diversi da quelli generati da computer x86, ma è normale.
Per i double non lo so, non so se sono scritti in formato diverso tra little/big endian. Bella questione, qualcuno ne sa qualcosa?
Credo di sì, dopo tutto si tratta sempre di un formato derivato dall'architettura del processore...per il controller della memoria andare a scrivere in memoria due int o un double è la stessa cosa.
Fammi capire: ti serve un formato generico per scrivere i dati in un file binario che sia compatibile con endianess diverse ?
Imho settare l'endianess non serve a niente, a meno che l'architettura di destinazione non supporti formati eseguibili con endiness diversi.
Se non setti l'endianess e rimani sulla stessa architettura non ti devi occupare del problema.
La mia applicazione fino a poco tempo fa ha girato sotto architettura x86. Adesso, per problemi su quella macchina, sono costretto ad usare una macchina con architettura Power.
Ora, sapevo che se portavo i binari creati sotto x86 in Power, avevo il problema del big endian, per questo li ho ricreati tutti sotto il Power.
Quindi, dovrebbero già essere in formato big endian.
Sapreste dirmi qualcosa sul problema postato e linkato nel thread sopra? Credo che la causa sia quella. :(
ilsensine
06-03-2008, 10:47
per il controller della memoria andare a scrivere in memoria due int o un double è la stessa cosa.
L'endianess non c'entra con il controller della memoria, ma come il processore memorizza i byte nei registri.
I valori in virgola mobile forse sono dettati da degli standard, quindi non sono sicuro se i big endian invertono i byte. Anche se da quello che dice Unrue sembrerebbe di sì.
ilsensine
06-03-2008, 10:51
Quindi, dovrebbero già essere in formato big endian.
Dovrebbero, e il programma dovrebbe funzionare senza problemi. A meno di errori di altro tipo, che dovresti investigare.
Sapreste dirmi qualcosa sul problema postato e linkato nel thread sopra? Credo che la causa sia quella. :(
Io non ne so nulla di quel MPI...
L'endianess non c'entra con il controller della memoria, ma come il processore memorizza i byte nei registri.
I valori in virgola mobile forse sono dettati da degli standard, quindi non sono sicuro se i big endian invertono i byte. Anche se da quello che dice Unrue sembrerebbe di sì.
Che senso ha parlare di little e big-endian sui registri del processore ?
Che io sappia riguarda solamente l'ordine con cui i dati vengono trasferiti dal controller nella memoria...
Come venga trasferito un double (8 byte) poi dipende ancora di più dal controller della memoria stesso...
ilsensine
06-03-2008, 11:25
Che senso ha parlare di little e big-endian sui registri del processore ?
Ha senso, per come il processore vede i byte dei registri:
union A
{
char bytes[4];
int value;
};
register A a;
register int b;
a.value = 0x01020304;
b = a.bytes[0];
Il compilatore può ottimizzare le variabili "a" e "b" in modo da mantenerle in due registri. L'accesso alla memoria può essere completamente evitato, eppure il risultato è diverso tra little e big endian.
Che io sappia riguarda solamente l'ordine con cui i dati vengono trasferiti dal controller nella memoria...
Esistono processori che consentono configurazioni "frankenstein": core big endian, bus little endian o viceversa.
Il risultato può essere diverso anche per scelta di traduzione in assembly, questo per mantenere coerenza fra l'accesso alla memoria e ai registri.
Imho a livello di assembly questa cosa non può esistere...cioè è come se accedessi ad AL ed ottenessi il byte più significativo di un intero.
ilsensine
06-03-2008, 11:58
Il risultato può essere diverso anche per scelta di traduzione in assembly, questo per mantenere coerenza fra l'accesso alla memoria e ai registri.
E se il controller scrive in memoria con un endianess diverso, che si inventa il compilatore?
Come ti ho detto, ci sono processori che consentono queste diavolerie. Ho letto il datasheet di uno di questi, non ricordo se era l'mx1 o qualche altro.
Ragazzi, se vi interessa ho risolto il problema della corruzione dei dati letti. Riguarda MPI-2, non la codifica big endian se volete ve la espongo.
E se il controller scrive in memoria con un endianess diverso, che si inventa il compilatore?
Come ti ho detto, ci sono processori che consentono queste diavolerie. Ho letto il datasheet di uno di questi, non ricordo se era l'mx1 o qualche altro.
Sono proprio masochisti certi progettisti ;)
banryu79
06-03-2008, 14:12
Ragazzi, se vi interessa ho risolto il problema della corruzione dei dati letti. Riguarda MPI-2, non la codifica big endian se volete ve la espongo.
Anche se non c'entro una ceppa sono interessato alla spiegazione :D
cdimauro
06-03-2008, 14:19
Certi processori possono operare in little o big endian (viene fissato dal s/o), in questi casi devi dire al gcc per quale tipo di architettura vuoi fare l'eseguibile. Un eseguibile per big endian non può essere eseguito su processori little endian, e viceversa.
Mi risulta che il PowerPC sia solo big endian, magari mi sbaglio.
Possono operare indifferentemente in little o big endian.
Inizialmente pensavo che i dati corrotti dipendessero dalla codifica big endian. Per leggere e scrivere i dati, uso routines di MPI-2, quindi letture e scritture parallele. Il file system su cui ero, SFS, non è parallelo, e fa casino quando si usano direttive parallele.
Passando su GPFS, il problema è scomparso :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.